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For an explanation qf the hm-teUer codes and the other 
abbreviations, reference is made to the eq>Iamaiom 
C'Giddance Notes on Codes and AbbrevfatioHs'') at the 
beginning of each r$guhr edition qf the PCT Gazette. 
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PT^rvrOCOL F ^ ^--^--rr,r, METHOP OF VEILING MID OP 

rmWERTING A T V^MWr^ADED PRQflBAM FRAGMENT, AND 
CQRRESPONPTNQ SYSTEJ^g 

The invention relates to a protocol for manag- 
ing, a method of verifying anii a method of transforming 
a do^loaded program fragment and the corresponding 
systems, more particularly intended for on-board data- 
processing systems having few resources available in 
terms of memory and of con«xuting power. 

in a general way, by reference to figure la, it 
is reiterated that on-board data-processing systems 10 
include a microprocessor 11, a permanent memory, such 
as a non-writable memory 12 containing tbe code of the 
executable program, and a rewritable, nonvolatile, per- 
n^ent memory 15 of EEPROM type containing the data 
stored in the system, a volatile, random-access memory 
14 in which the program stores its intermediate results 
while it is executing, and input/output devices 15 al- 
lowing the system to interact with its environment. In 
the case in which the on-board data-processing system 
consists of a ndcroprocessor card, of the bank-card 
type, the input/output device 15 consists of a serial 
link allowing the card to constiunicate witb a terminal, 
such as a card-reader terminal. 

in conventional on-board data-processing sys- 
tems, the code of the program executed by the system is 
fixed during construction of the system, or, at the 
latest, when the latter is customized before delivery 

to the final user. 

More sophisticated on-board data-processing sys- 
tems have, however, been implemented, these systems be- 
ing r^rogrammable, such as microprocessor cards of the 
javacard type, for example- With respect to the preced- 
ing types, these reprogrammable systems add the possi- 
bility of enhancing the program after the system has 
been put into service, via an operation of downloading 
program fragments. These fragments of programs, wxdely 
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designated l#applets-, will^ be designed applets, or 
prograja fragments indiscriminately in the present de- 
scription. For a more detailed description of JavaCard 
systems, reference cculd usefully be made to the docu- 
5 mentation published by the con5,any SDN MICROSYSTEMS 
INC., and in particular to the electronically available 
docmaantation, JavaCard tedhm^logy chapter, on the wv, 

iWoria ^ide ^-^^ 

http://java.sun.com/products/javacard/index.html, June 

10 1999. 

figure lb illustrates the architecture of such a 
reprogrammable on-board data-processing system. This 
architecture is similar to that of a conventional on- 
board system, with the difference that the Reprogramma- 
ble on-board system can moreover receive applets by way 
of one of its input/output devices, then store them in 
its permanent memory 13 f rom . which they can then be 
executed as a supplement to the main program. 

For reasons of portability between different on- 
board data-processing systems, applets are presented in 
the fona of code, for a standard virtual machine. -Ehis 
code is not directly executable by the microprocessor 
11, but it has to be interpreted in software terms by a 
virtual machine 16, which consists of a program resi- 
25 dent in a non-writable permanent memoiry 12. in the 
abovementioned exaHple of JavaCard cards, the virtual 
machine used is a subset of the Java virtual machine. 
For a description of the specifications relating to the 
Java virtual machine • and of the virtual machine used, 
reference could usefully be made to the work published 
by Tim LINDHOLM and Frank YELLIN. entitled "The Java 
Virtual Machine Specification-. Addi son-Wesley 1996. 
and to the documentation published by the company SON 
MICROSYSTEMS INC. "JavaCard 2.1 Virtual Machine Speci- 
fication", documentation available electronically on 
the www site http://Dava.sun.com/products/javacard/ 

JCVMSpec.pdf, March 1999. 
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The oUration of downloading appl# onto an on- 
board data-processing system in service poses consider- 
able security problems. An applet x^hicb is involuntar- 
ily or even deliberately, badly written may xncor- 
, rectly n«dify data present on the system, pr^ent the 
main program from executing correctly or at the right 
tiroe, or else modify other applets downloaded previ- 
ously, making them unusable or harmful. 

An applet written by a computer hacker may also 
0 divulge confidential information stored in the system, 
information such as the access code in the case of a 
bank card, for example. At the present time, three so- 
lutions have been proposed with a view to remedying the 
problem of security of a^jplets. 

A first solution consists in using cryptographic 
signatures, so as to accept only applets originating 
from trusted bodies or persons - 

in the aboyementioned example of a bank card, 
only the applets bearing the cryptographic signature of 
.0 the bank having issued the card are accepted and exe- 
cuted by the card, any other unsigned applet being re- 
jected in the course of the downloading operation. An 
ill-intentioned user of the card, not having available 
encryption keys from the bank, will therefore be inca- 
25 pable of executing an unsigned and dangerous applet on 
the card. 

This first solution is well adapted to the case 
where all the - applets originate from the same single 
source, the bank in the abovementioned exait5>le. This 

30 solution is difficult to apply in the case in which the. 
applets originate from several sources, such as, in the 
example of a bank card, the manufacturer of the card, 
the bank, the bodies managing, services by bank card, 
the large commercial distribution organizations offer- 

35 ing clientele loyalty programs and proposing, legiti- 
mately, to download specific applets onto the card. The 
Sharing and the holding among these various economic 
participants of the encryption keys necessary for the 
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Electronic s#.t«e of tba .,»Uts pc^^ior tac>u^- 
„1, economic and legal problems. ^ 

^ eeoona solution con.Ut. in carry^S «ut 
„^c cheese on access and on typing ■ during the «.cu.. 

°' rtX^tiution, the virtual .«c^e carrU. 

a certain n--^ °* 
the applets, such as: 

. check of access " the »«»ry: ^ each 

„^ «T-*»a the virtual, machine 

0 read or write in a laeiaory area, the . 

' verifies the right of .; access by the applet to the cor 

resT3onding data; 

. ayna^ic. verification of the data types, upon 

each instruction fr^ the asplet. the virtual machine 
verifies that the constraints on the data .types are 
Tatisfisd. By »ay of . ex»^e. the virtual machine W 
have special handling for data such as valid me^ry ad- 
^Lses. and prevent the applet generating invalid ^ 
^ — .. inteaer/address conversions or 
ory addresses by way of integer ^auoi. 

20 arittonetio operations on the addresses,- , 

. detection of staclc overflows and of illegal 
eccesses to the execution staclc of the virtual mchine 
^1 under certain conditions, are lively to dist^ 
^ operation thereof, to the point of circuwenti^ 
25 the preceding check mechanisms. ^ 

This second solution allows execution of a vdde 
.ange of applets under satisfactory ^^-'^^^^ ^r"^" 
tions. However, it features the drawback of a consider- 
able Slowing Of the execution, caused by the r^e of 
30 dynamic verifications. In order to obtain a reduction 
ir this slowing, some of these verif ications can be 
taken charge of by the microprocessor itself, at the 
cost, however, of an increase in the cc^lexitv there^ 
ana thus of the cost price of the on^board system Su^ 
35 verifications furthermore increase the re»airem«>ts for 
.andcm-access and permanent memory of the system by 
reason of the additional type information which it 
necessary to associate with the data handl«l. 
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A th#l solution consists ixx <0«Tring out a 

static verification of the code o£ the applet during 

the downloa<3ing. . 

, - 4-v,iK Btatic verification siinu- 
In this solution, this stata-c vex 

lates th« execution cf the applet at the level of ^e 
tvpes and estahlishec. once and fo. ^"'^^^ 
code of the applet conpliea »ith the rule of ^ 

of access control .^sed h. the ^irt-^ 
^ aoes not cause a staa. overflow. If 
^rification is successful, the applet can then be exe- 
Z.^ without it heing necessary dyna^cally to ver.^ 
this rule is coined «ith. In the event that the 
static verification process fails, the on-hoard system 
„de=ts the -applet, and does not allow its suhsequ^t 
«„cution, ror a «ore detailed description of the 
ahov^nentioned third solution, reference could useful^ 
be nade to the worlc published by Ti» ^nMO"' ^ 
VELLIN ^oted above, to the article published by ^a»s 
i .GOSLIRG entitled "Java Intermediate Byte Codes . 
p;oceedinBS of the MM SIG^i™. ^'"^^'^ 
Le Representations (IR-95), pages 111-118, January 
1995. and to the US patent 5,748,964 sranted on 
05/05/1998. 

conipared with the second solution, the thrrd so- 
lution presents the advantage of a n^oh m>re rapid exe- 
cution of the applets, since the virtual machine does 
not carry out any verification during execution. 

The third solution, however, features the draw- • 
back ot a process of static verification of the code 
which is complex and expensive, both in term of size 
of code necessary to conduct this process and in terms 
of si« of random-access nenory necessary to contain 
the intermediate results of the verification, and- xn 
terms of confutation time. By way of illustrative exam- 
ple, the code verification integrated into the Java TOK 
system marketed by SON MICROSYSTEMS represents about 50 
kbytes of »«chine code, and its consunption terms of 
^.access m««ory is proportional to (TP . Tr) x Hb, 
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^^re TP des0ates the naxlnu- stack s^. l^^iS" 

proBra». also widely deslgi»ted by »eU»d. of t..e aP 

These ^ry re^ire.«nts g«atly exceeded the 
fasciae, of the «.ou.cee o. the ^.ority of the pr.- 
,It-day on-board data-processing ayBt«», especially 
of commercially available microprocessor cards. 

se«ral variants of the third solution have been 
proposed, in which the -Titer of the applet sends to 
L verifier, in addition to the code of ^- -f^^'^' l 
, „f soeciflc supplementary information 
certain amount of praestablished 
such as precalculated data types or pr es 
proof of correct data typing. For a more detailed de- 
scription of the corresponding operating modes, refer- 
Tce could usefully be made to the articles published 
^ Bva BOSE and Kristoffer H8GSBB0 EOSB, -Lightwexght 
Stecode verification-, proceedings of ^ Worlcsh^ 
ron«l TOderspliming of Java, October 1998, and by 
Oeorge C. NECmA, -Sroof -Carrying Code-, Proceedings of 
the 24th AC« symposium Principles of ProBr««mina 1^- 
guages, pages 106-119, respectively. 

This supplementary information mafces xt possible 
to verify the code more rapidly and slightly to reduce 
the size of the code of the verification program but 
aoes not make it possible, however, to reduce the re- 
tirements for random-access memory, or even increaees 
^em, very substantially, in the case of the correet- 
data-typing preestablished-proof information. 

The object of the present invention is to remedy 
the abovementioned drav*ac)t8 of the prior art. 

m particular, one subject of the present inven- 
tion is the implementation of a protocol for managing a 
downloaded program fragment, or applet, allowing execu- 
tion of the latter by an on-board data-prooessxng sys- 
tem having few resources available, such as a mxcro- 
processor card. 
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^oJ^ B^:ect of the present i.#.tion is also 
the iwl^t^tion of a method of verifying a ^- 
the iiopj.em in whic2h a process 

loaded prosram fragment, or applet, in w 

static verification of the code of the ^ 
Iductea »hen it is downloaae.. this process possib^ 
Ling aligned, at least in its princi^e^ «^thjhe 
third solution descriW a^e. hut in 
fication techniques , are introduced, so as to allow «e 
ZL of this verification within the limits of values 
r^ry si.e and of co^tation speed i-oj^*- - 
^croprocessor cards and other low-power on-board data 

''""^ZZ:^^^^ - - present i.v«tion is also 
the impl^tation of methods of transforming progr». 
^Igmlts of conventional tvpe obtained, for «ca«ple, 
rC^us. Of a .ava co^iler on standardised program 
fragments, or applets, satisfying, a ^'^'^'^l''"^^ 
aon criteria of the verification method .whxch is the 
sib^ect of the invention, with a view to -'^--^^ 
the process of verifying and executing them at the 
level of present-day microprocessor c«:ds or on-board 

(iata-procesfiing systems. 

Another subject of the present inventxon xs. fi- 
nally, the production of on-board data^processing sys- 
. , ,..n™> of the abovementioned pro- 
tems allowing implementation of tne aoov 

tocol for managing and of the abovementioned method of 
verifying a downloaded program fragment - J ^ 
data-processing systems allowing i^lementation of the 
methods of transforming conventional program fragments, 
or applets, into standardized program fragments, or ap- 

tilots, as mentioned above. 

The protocol for managing a downloaded program 
fragment on a reprogr««»ble on-board system, which is 
the suhiect of the present invention, applies espe- 
cially to a microprocessor card e<^ipped with a rewri- 
table memory. The program fragment consists of an ob- 
ject code, a series of instnictions, executable by the 
^croprocessor of the on-board system ay way of a vir- 
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,,,,1 „«,*lne tui^ea »ith a. «cec«tio» ^clc «ith 
;::.l"ariabXes or x.ai.t«. ^iP^l^te. via ««ae xn- 
TZ:^i.ons and »^ it POa^iWe to iatexp«t tbi. *- 
rer=oa.. on-boara syst™ is inter=»n.="d to a 

ter^l.^ „o.«,orthy i« «,at it ==n.ist« least, 
of the <»-lx>ard .yst™. in detecting a 
for aownloadiug the pr<^» £ra«n^t <^ a 
!!^ve response to the sta,e consistiaB i» detecting 
positive e P further consists in reading 

a downloading command, it furtner con 
le object code constituting the progr^n fragment and 
" tL^orarily storing t^s object code in the r.«ri- 

^ry is subjected to a verification process, instruc- 
Lon by instruction. The verification process consist, 
ae ie^t in a stage of initializing the type staCc 
a>e table of register types representing the state of 
virtual .,«chine at the start of the execution of 
1 temporarily stored object code and in a succession 
of stages of verification, instruction by "-^ruction 

«.e existence, for ea^ current instructi-m. of a 
target, branching-instruction target, target of an ^- 
csption handler, and in a verification and an ^^ng 
of the effect of the current instruction on the type 
iLk and on the table of register types. Xn the ev»t 
Of » unsuccessful verification of the Object code, the 
protocol which is the Bubjec. of the invention consists 
L deleting the «»nentarily recorded progra-a fragment 

^ f>,= i.tter in the directory of 
when omitting to record the latter in 

available program frag^e^ts, and in sending an error 

code to the reader. 

. The ..«thod of verifying a prograa fragment down- 
loaded onto an on-board system, which is the subject of 

invention, applies especially to a 
card egui^d with a rewritable »en»ry "^ ^^ 

^ «v,-:e.r.*- code and includes at 
fraqment consiste of an object coae an 
cragiwB" ^ rvstructionB , execu- 

least one subprogram, a series of instruccio 
least w 1^ «^ the on-board system by 

table by the microprocessor of tbe on ou 
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, a vifu-l ™a=hin« «,uiPP.d vit*- execution 
stack and operand registers manip 

r^tLtiona, aad making it possible to interpret thxs 
T^^:tZ «>e on-board syste. is interconnected to a 

It is noteworthy in that, following the detec- 
ot a downloading =o«.-nd and the storage of ^ 
o^°ect code constituting the- program frag^^t xn the 
rrit.ble .^ry. it consists, for each a^rogr.«. ^ 
IZ.^, out a -ge Of initiaU.^g tbe^--* - 
the table of register types by data represen 
tne ^^■^ ^ +.v,e. ofcart o£ the execu- 

state of the virtual machine at the start o 

Tol of the ten^rarilv stored oMect code. ^ 
1 a verification of the te^rarily stored ^b.e^t 
code instruction by instruction, by discernxng the 
i^Le. for each current instruction, of a branching- 
istenoe. r „™t of an . axception-handler 

instruction target, of a taraet of an e* w „ 
can or of a target of a subroutine call, and rn carry- 
ing out a verification and an updating of the effect of 
ing out a ^. ^ fv.. data types of the type 

0,e current instruction on the data typ? 
ctacJc and of the table of register tipes, on the basxs 
of the e^astence of a branching- instruction target, of 
a target subroutine call or of a target of an excep- 
W^ler call. «>e verification is 
the table of register types is not -O-*"^ " ^ 
course of a verification of all the in»tmction=. the 
lification process being carried out instruction by 
instruction until the table of register "-^^ J" Jj^ 
ble, with no modification present. Otherwise the veri- 
fication process is interrupted. 

The method of transforming an object code of a 
p„gram frag^t into a standardized object code for 
Ls sa-e program fragment, which is the s^iect of^e 
p„sent invention, applies to an object code of a pro 
U fragment in which the operands of each ins tructi» 
^long to the data types »nipulated by this xnstruc^ 
1 1. the execution stack does not exhibit «^ — 
j>L^on and. for each branching instruction, the 



of the Jle^les o£ the .taclc at thi#>ranchiug is 

^ sa». as at *e tar,.ts of this branching.. ^^an- 
Tr^... eject coaa =.tainea is such «»t the cp«^ 
o£ each instruction belong to the data types n^nipu- 
LL ^ this instruction, the e:cecution .ta* does not 
e^it any overflow phenonenon and the execution stack 
is «.*ty at each branching-target instruction^ 

It is noteworthy in that it oon6a.sts, for all 
U» instructions o£ the ohiect code, in — f f^* 
«u^rent instruction with the data type of the execution 
stacc before and after the execution of this instruc- 
the annotation data being calculated by means of 
an analysis of the data strean. relating to this in- 
struction, in detecting, within the instructions and 
«itbin each current instruction. the existence of 
teanchings for which the execution stack is not e«pty. 
the detection operation being carried out on the basis 
o£ the »motation data of the type of stack varxablM 
allocated to each current instruction, m the pres^e 
of a detection of a non-e-pty execution stack, it fur- 
ther consists in insetting instructions to transf«: 
^tack variables on either side of these branchings or 
c£ these branching targets in order to e«pty th. con- 
tents of the execution stack into teroorary regxsters 
l,e£ore this branching and to reestablish the execution 
stack fron the t«.porary registers after this branch- 
ing, and in not inserting any transfer instruction oth- 

This method thus makes it possible to obtain a 
, standardized object code for this same program frag- 
^t. in which the execution stack is eTO>ty at each 
branching instruction and branching-target instruction. 

.e — , ^^AA f\ ration to the execution oi 
in the absence of any modxf xcacxon w 

the program fragment. 
5 The method of transforming an object code of a 

program fragment into a standardized object coda for 
this same program fragment, which is the subject of the 
present invention, applies, moreover, to an object code 
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of a progreun Ifcgm^t in which the operax# of each in- 
of a progxwn » manipulated by tiiis 

struction belong to the data types nva p 

«r,.q a operand of given type written into a 
instruction, and a operano « a 

^'-..p. -»'F this object code is re 
^^«4«t-er bv an instruction of tnxs ooj« 

t^fs cMect co.e with the sen. «iv«. a»ta t«« 
standardized object code obta^ed .8 _ ^_ 

erands belong to the data tvpes manipulated ^ this^ 
:Lctio„. one and the aa»e data type bei™ allocated 
to the same register throughout the standardized <*.ect 

xt is noteworthy in that it consists, for all 
«.e instruction, o. the object code, in 
current instruction vith the data type of the regist«s 
^tore and after the execution of this instruction, U» 
dotation data bains calculated by ~ane of an analy- 
tic of the data strea. relating to this ^truot.on. 
^ in carrying out a reallocation of "^^f^^^f " 
isters enployea with different types, by dxvxdxng these 
Iginal registers into separate 

^ers one standardised register is allocated to each 
a«ta type used. Reupdatlng of the instructions which 
l^pulate the operand, which use the standardised reg- 

isters is carried out. 

The protocol for .nanaglng a progras. fragT»ent. 
the method of verifying a program fragment, the methods 
Of tranafomdng object code of program frag»«.t8 into 
standardized object code and the corresponding syst»», 
which are the subjects of the present invention f^ 
an application in the develop.»ent of reprogranBBble on- 
board systems, such as microprocessor cards, especially 
in the Java environment. 

They will be better understood on reading the 
description and on perusing the drawings below, in 
i which, other than figures la and lb relating to the 
prior art: 
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- Mr. 2 r«pres«.tB « flow =#t illustrat- 
ing the protocol for »«n«in9 « program f«B^t dowu- 
o»to a .^o^a™=l>le 

_ Figure 3a represents, 
a flow c^rt of a ^.thod of verifying, a do«n- 

^ ^«T,t- in accordance with the sub3ect 
loaded program fragment xn accorum 

ftf tlie present .invention, 

. Figure 3b represents a diagraza illustratxng 
data types and sub-typing relationships i^lemented by 
data cypes method of verifying a 

the method of managing and the mecnoQ . ^ 

tne -wj^v* 4fl the subject of 

downloaded program fragment, vhxch xs the s D 

the present invention, 

. Figure 3c represents a detail of the verxfx- 
cation method as claimed in figure 3a,. relating to the 
managing of a branching instruction, 

- Figure 3d represents a detail of the verifx- 
cation method as claimed in figure 3a, relating to the 
n^aging of a subroutine-call instruction, 

_ Figure 3e represents a detail of the verifi- 
cation method as claimed in figure 3a, relating to the 
managing of an exception-handler target,. 

- Figure 3f represents a detail of the verifi- 
cation rhethod as claimed in figure 3a, relating to the 
managing of a target of incon5>atible branchings, 

- Figure 3g represents a detail of the verxfx- 
cation method as claimed in figure 3a, relating to the 
managing of an absence of branching target, 

- Figure 3h represents a detail of the verifi- 
cation method as claimed in figure 3a, relating to the 
waging of the effect of the current instructxon on 

the type stack, 

- Figure 3i represents a detail of the verifi- 
cation method as claimed in figure 3a, relati:ag to the 
managing of an. instruction for reading a 

- Figure 3j represents a detail of the verxfx 
cation method as claimed in figure 3a, relating to the 
nanaging of an instruction for writing to a register. 
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. Fillre 4a r«preBent» a flow cl#b iUustrat- 
^ a «e*od of tran^fo^ an object co^ of a 
^ f„B»a»t into a standardized object code, for this 
proZ f ra«.ent vith a branching inatmct.on re- 
:r=tL!y a branching-target instruction, w.th an 

'"""'rigure 4b represents a flow chart illnstrat- 
« method of transforming an object code of a pro- 
fragment into a standardized object code for this 
program fragment, making use of typed registers, a 
irgle. specific data type being attributed to each reg- 

- Figure 5a r^esents a detail of i«s.lementa- 
tion of the transformation method illustrated in figure 

. Figure 5b represents a detail of i™pla«enta- 
tion of the transformation method illustrated in figure 

- Figure 6 represents a functional diagram of 
tte oonplete architecture of a system for development 

a standardised program fragment, and of . reprogram- 
^le microprocessor card allowing i»plen>entati<» of 
the protocol for managing and the method of verxfying- a 
program fragment in accordance »ith the subject of the 

laresent invention. 

m general, it is indicated that the protocol 

fcr managing and the method of verifying and transform- 
ing a downloaded program fragment, which is the subject 
cf the present invention, and the corresponding sys- 
t«ns. are i^-lemented thanks to a software architecture 
for secure downloading and execution of applets on an 
on-board data-processing system with few resources, 
such as. in particular, microprocessor cards. 

in general, it is indicated that the description 
below concerns the application of the invention in th- 
context of reprograsnrable microprocessor cards of 
.avacard type, cf . documentation available <=l-«°"^- 
cally from the company SON MICROSYSTEMS IHC, JavaCard 
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^e=l»oxo^ heUn, ^entiU Previously l#:he d.scrip- 

Ha»«var, tiae present invention is applicable to 
.n-lK.a.d sy^te. which is .epro^««^le J. ^J- 
loUg an .pplet Which is written ^ a-e^-^e of a 

1 jj^^ an execution stacK/ xocai 
virtual machine including an execuvi 
virtuaj. vAilch the execution 

variables or registers, and o£ i^ch tne 
^el is strongly typed, each instruction of the c^e 
Z L applet applying only to specific aata types. ^ 
;.otocol for n^ging a Progra. £rag»«nt aownload^ 
onto a reprogra^able on-board system, v*.ch .s the 
Z>i^t of the present invention, will now be described 
in mora detail with reference to fig. 2- 

With reference to the Bbov«.«ntio=ed figure, it 
ie indicated that the object coda which .^kes up the 
program fragiaent or applet consists of a series of in- 
^r!Ition. Which can be executed by the -«°««°«"- 
of the on-board syste. by »«ans of th. abov««ntioned 
virtual machine. The- Virtual machine makes it possible 
to interpret the abovementioned object code. 
^ on-board syst^ is interconnected to a terminal 
via, for instance, a serial link. 

With reference to the abovementioned fig. 2. tne 
^ge.«nt protocol ^ich is the subject of the preset 
i^ention consists at least, in the on-board system, 
in detecting a command to download this program frag- 
ment in a stage 100a, 100b. Thns, stage 100a may con- 
sist of a stage of reading the abovementioned com-mnd 
snd stage 100b of a stage of testing the con^and whiCh 
has been read and verifying the existence of a down- 
loading command. ^^-^^ 
on a positive response to the abovementioned 

stage 100a, 100b of detecting a downloading command, 
the protocol which is the subject of the present oarvca- 
tion subsequently consists in reading, at stage 101, 
the object code which makes up the relevant program 
segment, and temporarily stor^g^he ^^-ed 
Object code in the memory of the on 
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processing s#:am. The .[bov«nentioned te#.rary storing 
operation can be executed either in the rewritable mem- 
ory or, if appropriate, in the rand«n-access inemory o£ 
the on-board system, when this has sufficient capac:Lty. 
The stage of reading the object code and temporarily 
storing it in the rewritable memory is designated as 
loading the code of the applet in fig. 2. 

The abovementioned stage, is then followed by a 
stage 102 consisting in submitting the whole of the 
tenporarily stored object code to a process of verif:t- 
cation, . instruction by instruction, of the abovemen- 

tioned object code. 

The verification process consists, at least in a 

stage of initializing the stack of types and the table 
of data types representing the state of the virtual ma- 
chine at the start . of execution of the ten«>orarily 
stored object code, and in a succession of stages of 
verif iying, instruction by instruction, by discerning 
the existence, .for each current instruction, designated 
. li, of a target such as a branching-instruction target 
designated CIB, a target of an exception-handler call 
or a target of a subroutine call, a verification and 
update of the effect of the current instruction X, on 
the stack of types • and on the table of register types 

is carried out. 

When the verification has been successful at 
stage 103a, the protocol which is the subject of the 
present invention consists in recording, at stage 104, 
the downloaded program fragment in a directory of 
available program fragments, and in sending to the 
reader, at stage 105. a positive reception acknowledg- 
ment. 

on the other hand, in the case of unsuccessful 
verification of the object code at stage 103b, the pro- 
tocol which is the subject of the present invention 
consists in inhibiting, in a stage 103c, any execution 
: on the on-board system of the momentarily recorded pro- 
gram fragment. Ihe inhibition stage l03c can be ixnple- 
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„.ented in vHou, ways. -As a nonXi^tin#«a««>le, this 
stage can cohaist delating, at stage 106, tHe luomea- 
tarily recorded program fragment, without recording 
this program fragment in the directory of available 
program fragments and, at stage 107, in sending an er- 
r:or code to the reader. Stages 107 and 105 can be im- 
plemented eith^ seqaentially after stages 106 and 104 
respectively, or in multitasking operation with them. ^ 

With reference to the same fig- 2, on a negative 
response to the stage consisting in detecting a down- 
loading command at stage 100b. the protocol which is 
the subject of the present invention consists in de- 
tecting, in a stage 108, a command to select an avail- 
able program fragment from a directory of program f rag- 
xnnnts and, on a positive response to stage 108, having 
detected the selection of an available program frag-' 
^t. in calling, at stage 109, this selected available 
program fragment in order to execute it. Stage 109 is 
then followed by a stage 110 of executing the called 
available program fragment by way of the virtual ma- 
chine, with no dynamic verification of variable types, 
rights of access to the objects which are manipulated 
by the called available program fragment, or overflow 
6f the execution stack wjien each instruction is exe- 
cuted. 

In the case where a negative response is ob- 
tained at stage 108, this stage consisting in detecting 
a command to select a called available program frag- 
n»ent, the protocol which is the subject of the present 
invention consists in proceeding, in a stage 111. to 
process the standard commands of the on-board system. 

Regarding the absence of dynamic verification of 
type or rights of access to objects of, for instance, 
javaCard type, it is indicated that this absence of 
verification does not conoromise the security of the 
card, because the code of the applet has necessarily 
successfully passed verification. 
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«xifl=atio„ vMch is carried out. a, clauned xn 
IILa «*ich io «.e subject =£ the pre.«.t invention 

the ™icropro=e...r car. or cn-^d aata-process 
Lsten. i. »ore 3elective ^ the cu.to»a^ v«.fxca- 
tlon of codes for the virtual Java machine as deecribed 
1» the work entitled "^e Java Virtual Machine Specifi- 
cation- «hi=h was .-^.tioned previously in the descrip- 

However, aw 9ode of the Java virtual .-chine 
„hich is correct as far as the traditional Java ve«- 
"Lr is concerned can be transformed into ax. e^^valent 
code which is capable of passing suocesefully the code 
verification which is carried out oa the lolcroprocessor 

" Whereas it ie possible to imagine writing di- 

rectly Java codes which satisfy the above»entioned . 
verification criteria mentioned in the context of im- 
plen«nting the protocol which is the subject of the 
20 present invention, a noteworthy object of the latter r. 
also the i<«,len>entation oi a i^thod of automtic trans- 
formation of any standard Java code into a standardized 
code for the same i«:ograi. fragment, necessarily satxs- 
fying the verification criteria i^lemented as i«en- 
25 tioned above. -ethod of transfoxmation stan- 

dardized code, and the corresponding system, will be 
described in detail subsequently in the description. 

A more detailed description of the method of 
verifying a program fragment, or applet, in accordance 
,d:th the subject of the present invention, will now be 
given with reference to fig. 3a and the subsequent fig- 
In general, it is indicated that the verifica- 
tion method which is the subject of the pres«.t inven- 
tion can be i^lemented either as part of the protocol 
for managing a program fragment which is the subject of 
the present invention as described above with reference 
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to fig. 2, <#independ«itly, to provide #iat ever veri- 
fication process is judged necessary. 

in general, it is indicated that a program frag- 
is made up of an object code including at least 
one subprogram, more commonly designated a method, and 
is made up of a series of instructions which can be 
executed by the ndcroprocessor of the on-board system 
via the virtual machine. 

AS sho«n in fig. 3a, the verification method 
consists, for each subprogram, in carrying out a stage 
200 of initializing the stack of types and the table of 
register types of the virtual machine by <aata repre- 
senting the state of this virtual machine at the start 
of execution of the object code which is the subject of 
verification. This object code can be stored teirqporar- 
ily as described above with reference to implementation 
of the protocol which is the subject of the present in- 
vention. 

me abovementioned stage 200 is then followed by 
a stage 200a consisting in positioning the reading of 
the current instruction Ii,, index i, on the first in- 
struction of the object code. Stage 200a is followed by 
a stage 201 consisting in carrying out a verification 
of the abovementioned object code, instruction by in- 
struction, by discerning the existence, for each cur- 
rent instruction, designated Ii, of a branching- 
instruction target CIB, of a target of an exception- 
handler call, designated CEM, or of a target of a sub- 
routine call CSR. 

The verification stage 201 is followed by a 
stage 202 of verifying and updating the effect of the 
current instruction Ii on the data types of the stack of 
types and of tbe table of register types, as a function 
of the existence, for the current instruction which is 
pointed at by another instruction, of a branching- 
instruction target CIB, of a target of a subroutine 
call CSR or a target of an exception-handler call CEM, 
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Stagiio2 for t±ie current instru<#on li is fol- 

on-» *.o tefit whether the last instruc- 
lowed by a stage 203 to tesc w«t3i-i«» 

tion has been reached, the test written as: 

It = last Instruction of the object code? 
on a negative response to test 203, the process passes 
to the next instruction 204, written i = i-1, and to 
the return to stage. 201. 

It is indicated that the abovementioned verifi- 
cation, at stage 202, has been successful when the ta- 
ble of register types is not modified during verifica- 
tion of all the instructions li which irake up the object 
code. For this purpose, a test 205 of the existence of. 
a stable state of the table of register types and pro- 
vided. laiiB test is written: 

5? Stable state of table of reglstBr types, 
on a positive response to test 205, verification has 

been successful- 

on the other hand, in the case where no absence 
of modification is noticed, the verification process is 
repeated and reinitiated by returning to stage 200a. It 
is demonstrated that the process is guaranteed to end 
after a maximum of NrxH iterations, where Nr designates 
the number of registers used and H designates a con- 
stant depending on the subtyping relation. 

Various indications concerning the types of 
variables which are manipulated in the course of the 
verification process described above with reference to 
fig. 3a will now be given with reference to fig. 3b. 

The abovementioned variable types include at 
least class identifiers corresponding to object classes 
which are defined in the program fragment which is sub- 
jected to verification, numeric variable types • includ- 
ing at least a type short , an integer coded on p bits, 
where the value of p can be 16, and a type for the re- 
turn address of a junj, instruction JSR, this address 
. type being identified as retaddr, a type null relating 
to references of null objects, a type .^j[ect relating 
to objects proper, a specific type i representing the 
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intersection^ all the types and corre#»nding to the 
value zero ^ml, another specific type T representing 
the union -of all the types and corresponding to any 

type of values. _ indicated that 

With reference to fig- 3t), ic xs m 
all the abovementioned variable types verify a subtyp- 
ing relation: 

object e t; 

short f retaddr eT; 

Xs null / short , retaddr 

A n»re specific exafl?>le of a process of verifi- 
cation as illustrated in fig. 3a will no«r be given, 
with reference to a first exainple.of a data structure, 
which is shown in table Tl in the annex. 

The abovementioned exaniple concerns an applet 

writtai in Java code. 

The verification process accesses the code of 
the subprogram which forms the applet which is sub- 
jected to verification via a pointer to instruction 1, 

which is being verified- 

The verification process records the size and 
type of the execution stack at the current instruction 
corresponding to saload in the exan©le of the above- 
mentioned Table Tl. 

The verification process then records the si?e 
and type of the execution stack at the current instruc- 
tion in the stack of types via its type stack pointer. 

AS mentioned above in the description, this 
stack of types reflects the state of the execution 
stack of the virtual machine at the current instruction 
Ii. In the example shown in table Tl, at the time of the 
future execution of . instruction li, the stack will con- 
tain three entries: a reference to an object of class 
C, a reference to a table of integers coded on p = 16 
bits, the type short [], and an integer of p = 16 bits 
of type short. T^is is also shown in the type stack, 
whici: also contains three entries: C, the type of 6b- 
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jec.B of claf C. BSortll, th, type ot ftleB of in«- 
Us P - " bits and sho«, the tvpe of intesers P = 16 

Jaother noteworthy data structure consists of a 
of register types, this tahle reflecting *e 
,«te of the registers, that is to say of the roBist^s 
which store the local variables, of the virtual ^- 

continuing the exai-ple indicated in table Tl, rt 
is indicat«J that entry 0 of the table of register 

. ^ ^ 4 o «i- the time of the future 
types contains type q, i.e» ^t the tiine 

execution of the current instruction = saload. regxs- 
ter 0 is guaranteed to contain a reference to an object 

of class C. ^ . . 

The various types which are nenipulated during 

verification and stored in the table o£ register types 

and in the type stack are represented in fig. 3b. These 

types include: .jt- 
class identifiers CB corresponding to apecxfxc 
object classes which are defined in the applet; 
base types, such as short , an integer coded on 
p = 16 bits, intl and int2, the most and least 
significant p bits respectively of integers 
coded on, e.g., 2p bitB, or retaddr, the return 
address of an instruction as mentioned above ; 
the type null, representing the references of 
null objects. 

Regarding the subtyping relation, it is indi- 
cated that a type Tl is a subtype of a type T2 if every 
valid value of type Tl is also a valid value of type 
T2. The subtyping between class identifier reflects the 
inheritance hierarchy between classes of the applet. On 
the other types, subtyping is defined by the lattice 
shown in fig. 3b. where i is a subtype of all types and 
all types are subtypes of T. 
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The liuence of the process of vf^fyi^ng a sub- 
program which for^ a. applet is as follows, referring 
to the abovementioned table Tl. 

The verification process is carried out inde^ 
pendently on each s^^program of the applet. For each 
subprogram., the process carries out oae or xnore ver.fx- 
cation passes on the instructions of the relevant, sub- 
program. The pseudocode of the verification process is 
given in table T2 in the annex. 

The process of verifying a subprogram begxns 
with initializing the type stack and the table of reg- 
ister types shown in table Tl, this initialization re- 
flecting the state of the virtual machine at the start 
of execution of the subprogram being examined. 

The type stack is initially eir5»ty, the stack 
pointer equals ^ero, and the register types are ini- 
tialized with the types of the parameters of the sub- 
program, illustrating the fact that tbe virtual machxne 
passes the parameters of this subprogram ix. these reg- 
isters, laie register types which are allocated by the 
subprogram are initialized to data types. J,, illustrat- 
ing the fact that the virtual machine initializes these 
registers to zero at the start of execution of the sub- 
program. 

Next, one or more verification passes on the in- 
structions and on each current instruction Ii of the 
subprogram aure ceirried out- 

At the end of the implemented verification pass, 
or of a succession of passes for instance, the verifi- 
cation process determines whether the register types 
contained in the table of register types shown in table 
Tl of the annex have changed during the verification 
pass, in the absence of change, verification is termi- 
nated and a success code is returned to the main pro- 
gram, which makes it possible to send the positive re- 
ception acknowledgment at stage 105 of the management 
protocol shown in fig* 2» 
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i£ a ftnge to th« abov««.tione<Able of reg- 
ister types is present, the verificetiox. process re- 
S« tfe verification pess unti. t.e re,lst« tvpee 
contained in the table of register types xs stable. 

,*e se<iaence proper of a verification paee «hxoh 
is carried out one or «ore ti»ee until the table of 
«gie.er types is stable will now be described w.th 

reference to fige- 3= to 3j. 

For each current instruction Ii. the follo»ing 

verifications are carried out: 

Kith reference to fig. 3a at stage 201, the 
verification process deterndnes whether the current in- 
struction I. is the target of a branchi.>g instruction, a 
subroutine call or an exception-handler call, as men- 
tioned above. This verification is carried out by exam- 
ining the branching instructions in the code of the 
sul^rogram and the, exception handlers associated wxth 

thi3 sut>prograin. ^ 

With reference to fig- 3c which begins wxth 
stage 201, when the current instruction H is the target 
of a branching instruction, this condition being ii«ple- 
ntented by a test 300 designated by ii = CIB, thxs 
branching being unconditional or conditional, the veri- 
fication process checks that the type stack is empty at 
this point of the subprogram by a test 301. On a posi- 
tive response to the test 301, the verification process 
is continued by a context continuation stage inarked 
continue A. On a negative response to the test 301, the 
type stack not being empty, the verification fails and 
the applet is rejected. This failure is represented by 

the Failure stage. 

With reference to fig. 3d which begins with the 
continue A stage, when the current instruction H is the 
target of a subroutine call, this condition being iia- 
plemented by a test 304 1^ = CSR, the verification proc- 
ess verifies, in a test 305, that the previous instruc 
tion I.-x does not continue in sequence. This verxfxca- 
tion is implemented by a test stage 305 when the prevx- 
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■ «h^ctfl is an unconditional brAing, a sub- 
o^s -^-^^f ^^^^ ^ exception, on^e teat 

routine return or a raising o 

at stage 305 is marked as follows: , . ^ x 

on a negative response to test 305, tbe verifi- 

in a Failure stage. On the other 
r<ntion process fails m a reixj-^^ 

cation i^iw verifica- 
>,=,r,r> on a positive response to test jua, 

1. It c«.tai„B e^cactly one entxy of E«ta^ type ^ 
*^«„ address c* the ^oven«utioned .^rout^ne. if t^e 
"^^t instruction I. at 3ta,e 304 is not «.e target 
Subroutine call, the verification- process .s contin- 
ued in the context at the continue B stase. 

With reference to fig. 3e. when the current in- 
struction I. is the target of ^ deception hax^er UUs 
condition being inplen>ented by a test 307 narked I. = 
Z. «here cm designates the target of an except.- 
handler, this condition is i,*lemented by a test 307. 

I- = CEM» 

on a positive response to test 307, the process veri- 
ties that the previous instruction is an unconditional 
branching, a subroutine return or a raising of excep- 
tions by a test 305, marked: , , 
I... = return RSR or raisins L- 

EXCEPT . . - . 

on a positive response to test 305, the verrfx- 

.ation process proceeds to reupdate the 
a stage 308. by entering exception types, i»ar)ced EXCEPT 
stage 308 being followed by a context continua- 
tion stage, continue C. On a negative response to test 
305 the verification process fails by the stage marfced 
Failure. The program fragment is then rejected. 

With reference to fig. 3£. when the current in- 
struction I. is the target of multiple incc^tme 
branchings, this condition is implemented by a test 
309, which is marked; 
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li a ^feoir?)atible XIBs ^ 
incc™«a.le br».<*in«. bein.. for ^te.c. a. uncon- 
ditional branching and a subroutine call, or t«o dit 
ferl exception handler., on a positive response to 
ZT209. the branching, being incompatible, the veri- 
fication process fail. ^ - stage ,«rHed failure and 
re prTgrl £rag««.t i. renected. on a negative re- 
ZJ:Z test 305. the verification process is cont^^ 
^fby a stage marked continue P. Test 309 beg^ wx«> 
^ continue C stage which was ..ntioned previously in 
the description. 

t.^ fir, -^fi when the current m- 
With reference to fig- 3g, wneii ^ 

*. ♦.>,o ^a■rfTGt of any branching, this 
struction li is not the target or any ^ ^ . 

. . 1 4-^^ w a test 310 beginning 
condition being implemented by a test 

with the abovementioned continue D, this test being 
marked 

li a? branching targets, 
where 3 designates the existence symbol, 
the verification procese continues on a negative re- 
sponse to the test 310 by passing to an up«aate of the 
type stack at stage 311, stage 311 and the positive re- 
sponse to test 310 being followed by a context con- 
tinuation stage at stage 202. which is described above 
in the description with reference to fig. 3a. 

A more detailed description of the stage of 
verifying the" effect of the current instruction on the 
type stack at the abovementioned stage 202 will now be 
given with reference to fig. 3b. 

According to the abovementioned figure, this 
stage can include at least one stage 400 of verifica- 
tion that- the type execution stack includes at least as 
r^y entries as the current instruction includes oper- 
ands. This test stage 400 is marked: 
ijbep - NOpi 

where Nbep designates the number of entries of the type 
stack and NQpi designates the number of operands in- 
cluded in the current instruction. 
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on a ititivB response to t«t 40#tWs test 

verifying U«t the type, of the -"i" 

top of the stac. are svhtypes of the types of the 
!!lranL ot the aho.eme»tioned current instruction. At 
:^rsta,e 40ia, the operand types of the ---^ 
are marked «)pi, and the types of the entr.es at the 
top of the stack are marked Targs. ^ ^ . 

Kt Stage 401h, the verification corresponds to a 
verification of the subtyping relation Targs subtype of 

on a negative response to tests 400 and Con,. 
the verification process fails, which is sho»n by ac- 
.:ess to the Failure stage. On the other hand, on a 
positive response to test 401b, the verification proc- 
ess is continued, and consists in carrying out: 

- A stage of verifying the existence of a suffi- 
cient n«moiy space on the type stack to P"^"*"' 
stack the results of the currant instruction. Thxs 
verification stage is i»pleiMnted by a test 402, 
marked: 

Stack-space * Results-space 
where, .each side of the ineqn>ality designates the corre- 

sponding wCTiory space. 

• On a negative response to test 402, the verxfi- 
cation process fails, which is shown by tHe Failure 
stage. On the other hand, on a positive response to 
test 402, the verification procefis then proceeds to 
stack the data type^ which are assigned to the results 
in a stage 403, the stacking being done on the stack of 
data types which aye. assigned to these results. 

AS a nonlimiting exainple, it . is indicated that 
to itrc^lement fig. 3h for verifying the effect of the 
current instruction on the type stack, for a current 
instruction consisting of a Java saload instruction 
corresponding to reading an integer element coded on p 
- 16 bits in a table of integers, this table of inte- 
gers being defined by the table of integers and an ix.- 
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i«aex #thi. ta^le. »d the re«.l#^ ^ inte- 
ger -hich is re,d at this ind^ in ^^^^ ^« 
Llfication pxoc... checks that the t:^ {"^"^'Z 
.«i„s at Xeast two elaaeots, that the two " " 
5 the top of the tvpe stack are subtypes of ahorttl and 
^rt respectively, proceeds to the .nstacki., process 
^then to the process of stacUng the data type short 

as the result type. 

Additionally, with reference to fig. 3x, to im- 
10 Pl'ement the stage of verifying the effect of the cur- 
Tent instruction on the type staC, when the current 
instruction li is a read instruction, marked IR, of a 
register of address n, this condition being ii.plemented 
by a test 404 marked I. = IRn. on a positive response to 
15 t:he abovementioned test 404, the verification process 
consists in verifying the data type of the result of 
this reading, in a stage 405. by reading the entry n in 
the table of register types, then in determining the 
effect of the current instruction li on the type stack 
20 by an operation 406a of unstacking the entries of the 
stack corresponding to the operands of this current xn- 
struction and by stacking 406b the data type of this 
result, -nie operands of the instruction H are marked 
OPi Stages 406a and 406b are followed by a return to 
25 the context continuation, continue F. On a negative re- 
sponse to test 404, the verification process .is contxn- 
ued by the context continuation, continue F. 

With reference to fig. Sj, when the current in- 
struction n is a write instruction, marked IW, of a 
30 register of address n, this condition being in^lemented 
by a test marked H = l^, on a positive response to 
test 407, the verification process consists in deter- 
mining, in a stage 408, the effect of the current in- 
struction on the type stack and the type t of the oper- 
35 and which is written in the register of address n 
then, in a stage 409, in replacing the type entry of 
the table of register types at address n by the type 
ixnmediately above the previously stored type and above 
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the type t of aper^a which is written^in the r«,- 

T^JZf aadr»« n. Stage 409 is foUowed by a return 
to the context continuation, continue 204. on a nega- 
tive response to test 407. the verification proceee .s 
continued )w » content continuation, continue 204. 

AS an exanple, when the current instruction I. 
corresponds to writing a value of type D into a regis- 
Z of address 1. and the type of register 1 before 
verification of the instruction was C. the type of reg- 
ister 1 is replaced by the type object, which is the 
«^lest type which is higher than C and D in the .lat- 
tice of types shown in fig. 3b. 

in the san« way. as an exai-ple, ,*en the current 
instruction I. is a read of an instruction aload-0 con- 
sisting in stacXing the contents of register 0, and en- 
try 0 of the table of register types is C, the v«:xfier 
Stacks C onto the type stack. 

jto example of verifying a subprogram written xn 
^ j^va environment will now be given, with reference to 
tables T3 and T4 in the annex. 

Table T3 represents a specific JavaCard code 
corresponding to the Java sxabprogram which is included 

in this table. 

table T4 shows the contents of the table of reg- 
ister types and of the type stack before verification 
of each instruction, me type constraints on the oper- 
ands of the various instructions are all observed. -Phe 
stack is eopty both after the instruction 5 to branch 
to instruction 9, symbolized by the arrow, and before 
the abovementioned branching target 9. The type of reg- 
ister 1/ which was initially i, becomes null, the upper 
bound o£ Hi^ and i , ^hen. instruction 1 to store a 
value of type null in register 1 is examined, then be- 
comes of type short []. the upper bound of types short [] 
and null, when instruction 8 to store a value of type 
Short [] in register 1 is processed. The type of regis- 
JlPx having changed . during the first verification 
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pa,s, a 3B=C#P«. is caxried out. distS-ti^g regis- 
te. tvpes v*lch were obtained at the «nd of the £.«t. 
This second verification pass is successful, just like 
the first, end does not change the register types. The 
versification process thus teii»inates suocessfully- 

various eKu^les of cases of failure of the 
verification process on fcmr e««.,les of incorrect code 

i ^-v, reference to table T5 in the an- 

will now be given with reference co 

At point a) of table T5, the porpose of the code 
given as an exainple is to atte«s>t to fabricate 
an invalid object reference using an arithmetic 
process on pointers. It is rejected by verifica- 
. tion of the types of arguments of instruction 2 
sadd, which requires these two arguments to be 
of type short . 

At points b) and c) of table T5. the purpose of 
the code is to carry out two attempts to trans- 
form any integer into an object reference. At 
point b) , register 0 is used simultaneously with 
type short, instruction 0 , and with type null, 
instruction 5. Consequently, the verification 
process assigns type T to record 0, and detects 
a type error when register 0 is returned as a 
result of type object at instruction 7. 
At point c) of table T5, a set of branchings of 
type "if ... then ... else is used to leave 

at the top of the stack a result which consists 
of either an integer or an object reference. The 
verification process rejects this code because 
it detects that the stack is not empty at the 
branching from instruction 5 to instruction 9. 
symbolized by the arrow. 

Finally, at point d) of table 5, the code con- 
tains a loop which, at each iteration, has the 
effect of stacking an additional integer on the 
top of the stack, and thus causing a stack over- 
flow after a certain number of iterations. The 
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verifHuon process rejects this#de, noti<.ing 
that the stack is not eir^ty at the baclcward 
branching from instruction 8 to instruction 0, 
symbolized by the return arrow, the stack not 
being en«)ty at a branching point. 

various exair^^les given above with reference 
to tables T3, T4 and T5 show that the verification 
process, which is the subject of the present invention, 
is particularly efficient, and that it applies to ap- 
plets, and in particular to subprograms thereof , for 
which the conditions of stack type, or . respectively of 
the empty character of the type stack previously, and 
to the branching instructions or branching targets, are 

satisfied. ^^^Aon 
Obviously, such a verification process iitS)lies 

writing object codes which satisfy these criteria, 
these object codes possibly corresponding to the sub- 
program in the abovementioned table T3 . 

However, and in order to ensure verification of 
existing applets and subprograms of applets which do 
not necessarily satisfy the verification criteria of 
the method which is the subject of the present inven- 
tion, in particular regarding applets and subprograms 
which are written in the Java environment, the purpose 
of the present invention is to establish methods of 
transforming these applets or subprograms into stan- 
dardized applets or program fragments, making it possi- 
ble to undergo successfully the verification tests of 
the verification method which is the subject of the 
present invention and of the management protocol which 
iitplements such a method. 

For this purpose, the subject of the invention 
is the implementation of a - method and a program for 
transforming a traditional object code forming an ap- 
plet, it being possible to itnplement this method and 
this transformation program, outside an on-board system 
or microprocessor card, when the relevant applet is 
created • 
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The ILod Of tr^foriiog code standard- 
ised code. Which is the subiect the present inv^ 
tL. will a- be de3crih.d in the £x«^rfc of the 
a«va e»vir<«n>ent, as a purely illustrative «a««>le. 

The av« codes which are produced by existing 
aava co-Pllers satisfy various criteria, which are 

Stated below: ^ n v-. 

' . the arguments of each instruction actually be- 
■ long to the types which this instruction «c- 

pects; 

C2 . the stack does not overflow; • 

C.3. for each branching, ins tructioa, the type of the 
stack at this branching is the same as at the 
possible targets for this branching; 
C'A- a value of type t which is written into a regis- 
ter at one point of the code and reread from the 
same register at another point of the code is 
always reread with the same type t; 
The ixrplementation of the verification method 
20 which is the subject of the present invention implies 
that criteria C'3 and C'4, which are verified by the 
object code which is submitted for verification, be re- 
placed by criteria C3 and C4 below: 

C3; the stack is enpty at each branching instruction 

and at each branching target; 
C4: the same register is used with one and the same 
type throughout the code of a subprogram. 
With reference to the abovementioned criteria, 
it is indicated that Java conpilers guarantee only the 
30 weaker criteria C-3 and C'4, OOie verification process 
which 13 the subject of the present invention and the 
corresponding management protocol in fact guarantee 
n^re restrictive criteria C3 and C4, making it possible 
to ensure the security of execution and management of 

35 applets. , 

The concept of standardization, covering the 

transformation of codes into standardized codes, can 
present various aspects, to the extent that replacement 
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of criteria <• -nd C-4 by criteria « # «. in con- 
formity with the verific=atio:* proce« which i« ^he .ub- 
!^of the present invention, can he in^le»ented ^ 
Ldently, to ensure that the atack is at each 

Clnl inat«=tion and at each br«.chin« target, and 
"^^tiU that the registers which the a^-Xet 
„/typed, and a single data type which is aaaxgned for 
^Cioa of the relevant applet correapc^da to ea^ 

^ register, or. on the other hand. " 

isfy the Whole Of the verification process whxch is the 

subject of the present invention. 

The n«thod of trans£or«dag an object code xnto 

standardized object code as claimed in the invention 
conse^eatly be described as clain«d in two d^- 

Unct i^l-nentation n^ea, a first i^le««xtation ^ 

corresponding to transforation of an object code which 

n't r"^ c'4 into a standaraizea 
satisfies criteria CI, C2, C 3. C 4 uit^o 

object code which Batxefies criteria CI, C2, C3, 
corresponding to a standardized code with an ^ty 
branching instruction or branching target, then as 
claimed in a second implementation mode, whxch the 
traditional object code which satisfies the same ini- 
tial criteria is transformed into a standardized object 
code which satisfies criteria Cl, C2. C'S, C4, for in- 
stance corresponding to a standardized code usiag typed 
registers. 

The first iinplementation mode of the code trans- 
formation method which is the subject of the present 
invention will now be described with reference to fig. 
4a. in the implementation mode which is shown xn fxg. 
4a the initial traditional code is considered to sat- 
isfy criteria Cl+C2-.C'3. and the standardized code 
vhich.is .obtained as the result of the transformation 
is considered to satisfy criteria C1+C2+C3 . 

According to the abovementioned figure, the 
transformation method consists, for each current in- 
struction I. of the code or of the sui^rogram, in anno- 
tating each instruction, in a stage 500, with the data 
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of the facie b^iori and after exe^ion of this 
: r^^ction. a^otation data is ^r.ed ^d x3 

r^eociated the reXatio. U^^. with the releva.^ 
cLent instruction. The annotation data is calculated 
Heans of an analysis of the data strea. relatxn. to 
this instruction, data types before and after exe- 

cution of the instruction are n^rlced the, and tae. re- 
:rectively. Calculation of anno.a.ion data ^ analysis 
Z the data strea. is a traditional calculation whxch 
is kno«n to those skilled in the art, and will there- 
fore not be described in detail. 

The operation which is inplemented at stage 500 
is illustrated in t^le t6 in the annex, in w^ch for 
an applet or suhprogram of an applet including 12 in- 
•structions, the annotation data Ali made up of the types 
of registers and the types of the stack are introduced. 

The abovemention^d stage 500 is then followed by 
a stage 500a consisting in positioning the index i on 
the first instruction 1, « Ii- Stage 500a is followed by 
a stage 501 consisting in detecting, among the instruc- 
tions and in each current instruction 1.. the existence 
. of branchings ntarked IB or of branching targets CIB for 
which the execution stack is not en5>ty. This detectxon 
501 is iit«>l«nented. by a test which is carried out on 
the basis of the annotation data AI, of the type of 
stack variables allocated to each current instruction, 
the test being marked for the current instruction. 

li is an IB or CIB and stack (AI) ? enpty. 
on a positive response to test 501, i.e. in the 
presence of detection of a non-en«,ty execution stack, 
the abovementioned test is followed by a stage consist- 
ing in inserting instructions to transfer stack var:L- 
ables on either side of these branchings IB or branch- 
ing targets CIB, in order to e«5,ty the content of the 
execution stack into te««)orary registers before thxs 
branching and to reestablish the execution stack from 
the ten^orary registers after this branching. The 
sertion stage is ^rked 502 in fig. 4a. It xs followed 
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^ e. Stage 503 to test r^^ching the last instruction, 

marked 

li = IdBt instruction? 
on a xiegativ. response to the test 503, an increment 
S04 i=i+l is carried out, to go. on to the next instruc- 
tion and return to stage 501. On a positive response to 
test 503, an End stage is initiated. On a negative re- 
sponse to test 501, the transformation method xs con- 
tinued by a branching to stage 503 in the absence of 
insertion of a transfer instruction. Implementation of 
the method of transforming a traditional code into a 
standardized code with branching instruction with erc?,ty 
stack as represented in fig. 4a makes it possible to 
obtain a standardized ohject code for the same initial 
program fragment in which the stack of stack variables 
is es^ty at each branching instruction and each branch- 
ing-target instruction, in the absence of any modifica- 
tion to the execution, of the program fragment. In the 
case of a Java environment, the instructions to trans- 
fer data between stack and register are the load and 
store instructions of the Java virtual machine. 

Returning to the exainple introduced in table T6, 
the transformation method detects a branching target 
where the stack is not empty at instruction 9. Tha 
, xnethod is then to insert an instruction istore_l before 
the branching instruction 5 which leads to the above- 
mentioned instruction 9, in order to save the content 
of the stack in register 1 and ensure that the stack xs 
ertpty at the time of the branching. Symmetrically, an 
instruction iload 1 is inserted before the instruction 
target 9, to reestablish the content of the stack ex- 
actly as it was before the branching. Finally, an in- 
struction istore 1 is inserted after inetruction 8 to 
ensure that the stack is balanced on the two paths 
which lead to instruction 9. Ihe result of the trans- 
foxmation carried out in this way into a standardxzed 
code is shown in table T7 . 
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The second implementation mode of the transfor- 
ation ^thod Which is the subject of the preset in- 
vention will now be described with reference to fig. 4b 
in the oa.e in which the initial traditional object 
code satisfies criteria CUC-i and the standardized ob- 
ject code satisfies criteria CI+C4. 

With reference to the aboveinentioned fig. 4b, xt 
is indicated that the method, in this implementation 
consists in annotating, as claimed in a stage 500 
which is approxix^tely the sa«« as that whidi xs shown 
in fig. 4a, each current instruction I. with the type of 
register data before and after e«cution of this in- 
atxuction. in the sa»e way, the annotation data AH xs 
calculated by means of an analysis of the data stream 
relating to this instruction. 

The annotation stage 500 is then followed by a 
stage consisting in carryl^ out a reallocation of the 
registers, the stage «arlced 601, by detecting the 
original registers ^.ployed with • different types, by 
dividing these original registers into separate stan- 
dardised registers, one standardised register bei^g al- 
located to each data type used. Stage 601 is followed 
by a stage 602 of reupdating the instructions which ma- 
nipulate the operands ^ch use the abovementioned 
standardised registers. Stage 602 is followed by a con- 
text contintiation stage 302. 

Witt reference to the exaanple given in table T6. 
it is indicated that the transformation method detects 
that the register of rank 0, marked rO, is used with 
t:he two types, object, instructions 0 and 1, and 
instruction 9 and following. The method is then to di- 
vide the original register rO into two registers, reg- 
ister 0 for the use o£ object types and register 1 for 
uses of int type. References to record 0 of int type 
are then rewritten by transfonning them into references 
to record 1, the standardised code obtained being shown 
in table T8 in the annex. 
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It is noted, dn a nonlimitinff way/ that in the 
exa^le Which is introduced with reference to the 
ahoveraentioned tabl. T8, the new register 1 is used si- 
n^ltaneously for standardization of the -^^^ ^^J^^ 
creation of typed registers by dividing of regxster 0 

into two registers. 

Ihe ..ethod of transforndno ^ traditional code 
l„to a standaraized code with branching instruction 
with en^ty «tack as described in fi«. -'^^ 
described in «>re detail in a preferred, nonli.«itxng 
in>plen.entation mode, in relation to fig. 5a. 

This inplamentation mode concerns stage 501, 
consisting in detecting, within the instructions and 
within each curr«it instruction I., the existence of 
branching IB, or respectively of branching target CIB, 
for which the stack is not en(pty. 

Following the deten»ination of target instruc- 
tions where the stack is not e»«,ty, this condition be- 
ing ,nark«J at stage 504a, I> stack#enpty, the transfor- 
ation process consists in associating «ith these ^- 
Btructions. at the abovementioned stage 504., a set of 
^ registers, one per ' stack location which is active 
at these instructions. Thus, if i designates the rank 
of a branching target of ^ich the associated stack 
type is not «.«,ty and is of type tpU to tpn^ with n > 
0 stack not e»i.ty. the transformation process allo- 
cates n new, as yet unused, registers, r. to r„ and as- 
eociates then, with the correspondl^fl instruction 1. 
This operation is implemented at stage 504a. 

Stage 504a is followed by a stage 504 consisting 
in examining each detected instruction of rank i and 
identifying, in a test stage 504, the existence of a 
branching target CIB or of a branching IB. Stage 504 is 
shown in the fon» of a test designated by: 
3?CIB,IBandIi=ciB. 

in the case that the instruction of rank i is a 
branching t^get CIB represented by the preceding 
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aqaaUty, and Zt tfca: stack of .tack variabT.s at this 
i^truction is n6t en^ty. i.e. with a positiv. response 
to test 504, for every preceding instruction oJ rank 
i.l ociiBiBting o* a branching, a raising of an exer- 
tion or a program return, this condition is implemented 
at test stage 505, designated by: 

J, , = IB, EXCEPT raising. Prog, return. 
The detected instruction of rank i is onXy accessible 
^ a branching. On a positive response to the abov««en- 
tioned test 505, the transforr<«tion process consists xn 
carrying out a stage 506 consisting in inserting a set 
of Toad instructions of load type fro. the set of new 
registers before the relevant detected instruction of 
rank i. The insertion operation 506 is followed by a 
redirection 507 of all branchings to the detected In- 
Btruction Of rank i. tc the first inserted load ^- 
struction load, ihe insertion and redirection opera- 
tions ore shown in table T9 in the annex. 

For every preceding instruction of rank i-l con- 

i a «*en the current instruction 
tinUing in sequence, i.e. wnen wre 

of rank i is accessible simultaneously by a branching 
fron the preceding instruction, this condition toe- 
ing inplemented by test 508 and symbolized by the rela- 
tions: 

Ii-i-^Ii 

and 

the transfoimation process consists in a stage 509 of 
inserting a set of backup instructions store to back 
to the set o£ new registers before the detected in- 
struction of rank i, and a set of load instructions 
load to load from this set of new registers. Stage 509 
iTihen followed by a stage 510 of redirection of all 
the branchings to the detected instruction of rank x to 
the first inserted load instruction load- 
In the case that the detected instruction of 
rank i is a branching to a determined instruction, for 
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ZditW^al brancMng. this condition bain. i™,l»eated 
by a test 511 marked: 

d>e transformation process as sha»n in fig- 5a conslstB 
* inserting at a atase 512. on a positive responaa to 
" t 511. befora tha datected instruction of rank i, 
Tltipl- bacl^p instructions store. The transformation 
: :l inserts ^fore t.e instruction i 
tions store as aho« in talkie Til as an 
instrac'^I^s store address registers r. to '^■^^^-^ 
Lignatea the nunO^er of registers. «.ua the lookup xn- 
struction is associated with each new register. 

For every detected instruction of raiA i con- 
sisting of » conditional branching, and for a nuriber 
Z i-'^er than 0. of operands s^pulated ^ thxa- 
c^tional branching instruction, this condition bexng 
ix^plemented by the test 513 marked: 

liSlBccmdit. 

with mop > 0 

the transformation process, in positive response to the 
abovementioned test 513. consists of Inserting, at a 
stage 514 before this detected instruction of ^ 
penrntation instruction marked swapjc at the top of the 
stack of stack variables of the ««. operands of the de- 
tected instruction of rank i and the n following val- 
ues This permutation operation makes it possible to 
collect at the top of the stack of stack variables the 
„ values to be backed up in the set of new registers rr 
to r.. Stage 514 is followed by a stage 515 consxstxng 
in inserting, before the instruction of rank r. a set 
of backup instructions store to back up to the set of 
^ registers r, to r.. The aboven.entioned insertion 
.tage 515 is itself followed by a stage 516 of inser- 
tion, after the detected instruction of rank i. of a 
set of load instructions load to load from the set of 
: n^ registers r. to r.. set of corresponding inser- 
ti«. operations is shown in table 12 in the annex. 
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For r.«onB of oirpletenesa and with ref«:en,;e 
5a. it is indicated that, on a negative re- 
sponse to test 504, the continuation of the transfor^- 
Tcn process is i^len^nted ^ a context continuation 
tl«e continue 503, that the negative -^P°-« '° 
^e^ts S05, 508, 5U and 5i3 is itself foUowed by a 
continuation of the transformation P^""" \ 
text continuation stage, continue 503, and that the 
.an>e applies to the continuation of operations after 
aboven^tioned redirection sta.es 507 and 510 and 

insertion stages 512 and 516. 

A ,«,re detailed description of the method of 
standardizing and transformng an oMect code into a 
standardized object code using t«»d registers as de- 
scribed in fig. 4b will now be given with reference to 
fig. 5b. This implementation mode concerns, more par- 
ticularly, a nonliadting. preferred implementation mode 
of stage 601 to reallocate registers by detecting the 
original registers used with different types. 

With reference to the abovementioned frg. 5b. rt 
is indicated that the abovementioned etage 601 consists 
i„ deten-dning. in a stage 603. the lifetime intervals 
„«rked ID, of each register r,. These lifetime inter- 
vals, designated -live range" or ■»ebs' . are defined 
for a register r as a maximum set of partial traces 
such that register r is live at all points of these 
traces. For a more detailed definition of these con- 
c^ts, it is useful to refer to the work edited by Ste- 
ven s. MOCHNICK entitled -Advanced Co«t>ller Design and 
B™,lemsntation- , Section 16.3, Morgan KAOTHMM, 1997. 
Stage 603 is designated by the relation: 
ID]< — >r) 

aB claimed in which a corresponding lifetime internal 
ID. is associated with each register rj. 

The abovementioned stage 603 is followed by a 
stage 604 consisting in determining, at stage 604, the 
^in data type, narked tp„ of each lifetime interval 
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jB, The type of a lif.ttte interval ID,, for a 

register r„ i» defined by the upper of the data 

types stored in this register r, by the backup instruc- 
tions st«e belonging to the abovementioned lif et^ 
interval. 

Stage 604 is itself followed by a stage 605 coxi- 
sisting in establishing an interference graph between 
the lifetiiae intervals as defined above at stages 603 
and 604, this interference graph consisting of a non- 
oriented graph of which each peak consists of a Ixfe- 
time interval, and of which the arcs, marked a^.i. on 
fig 5b, between two peaks and XD„, exist if a peak 
contains a backup instruction addressed to the register 
of the other peak or vice versa. In fig. 5b, the con- 
struction of the interference graph is shown syinboli- 
cally, it being possible to i^len^t this construction 
on the basis of calculation techniques which are known 
to those skilled in the art. For a more detailed de- 
scription of the const^ction of this type of graph, xt 
is useful to refer to the work published by Alfred V. 

Ravi SETHI and Jeffrey D. ULLMAN entitled 
-Coit5)ilers: principles, techniques, and tools", Addx- 
son-Wesley 1986, Section 9-7. 

Following stage 605. the standardization method 
as shown in fig. 5b consists in translating, in a stage 
606, the uniqueness of a data type which is allocated 
to each register rj in the interference graph, by adding 
arcs between all pairs of peaks of the interference 
graph while two peaks of a pair of peaks do not have 
the same associated main data type. It is understood 
that the translation of the character of uniqueness of 
a data type which is allocated to each register obvi- 
ously corresponds to translating and taking into ac- 
count criterion C4 in the interference graph, this cri- 
terion being mentioned previously in the description. 
Tlie abovementioned stage 606 is then followed by a 
stage 607 in which an instantiation of the interference 
. graph is carried out, this instantiation being more 
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co««nPx.ly de.si^?ea a. the painting ^^^^^ f . "^^^ 
f^xence graph as claimed in tho usual techniques. Dur 
ing stage 607, the transforation ^^^^ ^^^^^^ ^ 
each lifetime interval IPj. a register nuiriber rk, xn 
such a way that two adjacent intervals in the interfer- 
ence graph receive different register nurtibers. 
ence grap* ^^lemAnted on the basis 

This operation can be ia«>lementea on 

of any suitably process, as a nonliMting example, it 
is indicated that a preferred process can consist: 

in choosing a peak of minimum degree in the xn- 
terference graph, minintum degree being defxned 
as a mininruia number of adjacent peaks, and with- 
drawing it from the graph. This stage can be re- 
peated until the graph is empty. 
Each previously withdrawn peak is reintroduced 
into the interference graph in the inverse order 
of their withdrawal, the last to be removed be- 
ing the first to be reintroduced, and succes- 
sively in the inverse order of the order of 
Withdrawal. Thus the smallest register number 
which is different from the numbers assigned to 
all the adjacent peaks can be assigned to each 
reintroduced pealc. 
.i^ally. ^ «t«g. 602. shown in the «ansf«- 

^tio^ «,d reallocation procesB re-rites the access in- 
structions to the registers in the code of the svhpro- 
gram of the relevaxit applet. Access to a fliven reg.st«r 
i„ the corresponding lifetime inter«l is replaced by 
access to a different resrister, the n-»ber of whxch has 
been assianed during the instantiation phase, also des- 
ignated the painting phase. 

A Bore detailed description of an on-board data- 
processing system, making it possible to l^lement the 
^gement protocol and verification process of a pro- 
gram fraginent or applet as clain«d in the subject of 
the present invention, and of a development system of 
an applet, will now be given with reference to fig. =. 
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Regarding the- corteBpondina 6n-boafd system with 
reference 10. it is ««lled that this on-board system 
is a reprogrsK™i=le-type system, including the essen- 
tial =«Wonents as shown in fia. lb. The abovementioned 
o„-boara system is considered to be interconnected to a 
terminal by a serial link, the terminal itself be.n, 
linked, for instance via a local network, if appropri- 
ate a remote network, to an applet development computer 
„ith reference 20. On the on-board system 10 runs a 
main program, which reads and executes the coHu^mds 
which the ten«inal sends on the serial link. Addition- 
ally, the standard commands for a microprocessor card, 
such as for instance the standard commands of the ISO 
7ei6 protocol, can be implemented, and the main program 
recognizes two additional commands, on. for remote 
leading of an applet, and the other for selecting an 
applet ^ch has previously been loaded onto the micro- 

processor card. 

in conformity with the siobject of the present 
invention, the structure of the main program is impXe- 
„,eated in such a way ae to include at least one program 
^dule for management and verification of a downloaded 
program fragment, following the protocol for managing a 
downloaded program fragment as described above in the 
description with reference to fig- 2. 

Additionally, the program module also includes a 
subprogram module to verify a downloaded program frag- 
„.ent, following the verification method as described 
above in the description with reference to figs. 3a to 

For this purpose, the structure of the memories, 
in particular the non-writable permanent memory ROM, is 
modified in such a way as to include in particular, 
apart from the main program, a protocol management and 
verification module 17, as mentioned above. Finally, 
regarding the nonvolatile rewritable memory of EEPROM 
type, this advantageously includes a directory of ap- 
plets, marked 18, making it possible to implement the 
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«^nagement protocol and verification process which are 
the subjects of the present invention. 

With reference to the same fig- 6, it is indi- 
cated that the applet development system conforming to 
5 the subject of the present invention, in fact making it 
possible to transform a traditional object code as men- 
tioned above in the description, and satisfying crite- 
ria Cl-»-C2+C'3+C-4 in the framework of the Java environ- 
ment, into a standardized object code for the same pro- 
10 gram fragment, includes, associated v,ith a traditional 
Java compiler 21, a code transformation module, marked 
22 which proceeds to transform code into standardized 
code as claimed in the first and second i««>leiaentation 
„,odes described above in the description with reference 
15 to figs. 4a, 4b and 5a, 5b. It is in fact understood 
that on the one hand, standardization of the original 
object code into a standardized object code with 
branching instruction with en^pty stack and into a stan- 
dardized code using typed registers, on the other hand, 
20 as mentioned previously in the description, makes it 
possible to satisfy verification criteria C3 and C4, 
which are ii^posed by the verification method which is 
the subject of the present invention. 

The code transformation module 22 is followed by 
25 a Javacard transformer 23, which makes it possible to 
ensure transmission by a remote or local network to the 
terminal and, via the serial link, to the microproces- 
sor' card 10. Thus the applet development system 20 
shown in fig. 6 makes it possible to transform the com- 
30 piled class files produced by the Java compiler 21 from 
the Java source codes Of the applet into class files 
which are equivalent, but which observe the additional 
constraints C3, C4 which are ir^posed by the management 
protocol and the verification module 17 on board the 
35 microprocessor card 10. These transformed class files 
are transformed into a downloadable applet on the card 
by the standard JavaCard transformer 23. 



Varic^ particularly noteworthy ^omponents of 
the set of protocol ci^onents, methoaT and systems 
which are the subjects of the present invention will 
now be given for information only. 

compared to the verification processes of the 
prior art as mentioned in the introduction to the de- 
scription, the verification method which is the subject 
of the present invention appears noteworthy in that it 
concentrates the verification effort on the typing 
properties of the operands which are essential to the 
security of execution of eacH applet, i.e. observing 
tbe type constraints associated with each instructxon 
and absence of stack overflow. Other verifications do 
not appear to be essential in terms of security, in 
particular verification that the code correctly xni- 
tializes every register before reading it for the first 
time, on the contrary, the verification method which is 
the subject of the present invention operates by ini- 
tializing to zero all the registers from the virtual 
xnechine when the method is initialized, to guarantee 
that reading a non-initialized register cannot compro- 
mise the security of the card. 

Additionally, the demand iirposed by the verifi- 
cation method which is the subject of the present in- 
vention, as claimed in which the stack must be enpty at 
each branching or branching target instruction, guaran- 
tees that the stack is in the same state, empty, after 
execution of the branching and before execution of the 
instruction to which the program has branched. This 
mode of operation guarantees that the stack is xn a 
consistent state, whatever the execution route which is 
followed through the code of the relevant suhprogram or 
applet. The consistency of the stack is thus guaranteed 
even in the presence of a branching or branching tar- 
get, contrary to the methods and systems of the prior 
art. in which it is necessary to conserve in random- 
access memory the type of the stack at each branching 
target, which necessitates a quantity of ra.^dom-access 



memory proport Al to T^pxNb. the product # the loaxi- 
ntcan size of execution stack which is used and the num- 
ber of branching targets in the code, the verification 
method which is the subject of the present invention 
only needs the type of the execution stack at the time 
of the instruction during verification, and it does not 
keep in memory the type of this stack at other points 
of the code, consequently, the method which is the sub- 
ject of the invention is satisfied with a quantity of 
random-access memoiy proportional to Tp but independent 
of Nb, and consequently of the length of the code of 
the subprogram or applet. 

The requirement as claimed in criterion C4, as 
claimed in which a given register must be used with one 
and the same type throughout the code of a subprogram, 
guarantees that the abovementioned code does, not use a 
register in an inconsistent way, e.g. by writing a 
short integer to it at one point of the program and re- 
reading it as an object reference at another point of 
the program. 

In the verification processes which are de- 
scribed in the prior art, in particular in the previ- 
ously mentioned Java specification entitled 'The Java 
Virtual Machine Specification", edited by Tim LINDHOLM 
and Frank YELLIN, to guarantee the consistency of the 
abovementioned uses through the branching instructions, 
it is necessary to keep in random-access memory a copy 
of the table of register types at each branching tar- 
get. This operation necessitates a quantity of random- 
access memory proportional to T,«Nb, where T^ designates 
the nuiiiber of registers used by the subprogram and Nb 
the number of branching targets in the code of this 
subprograiti - 

On the contrary, the verification process which 
is the subject of the present invention operates on a 
global table of register types without keeping a copy 
at different points of the code in random-access mem- 
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cry. consequent^, the .random-acceps memos' which is 
required to implement the verification process is pro- 
portional to but independent of N., and consequently 
of the length of the code of the. relevant subprogram. 

The constraint as claimed in which a given reg- 
ister is used with the same type at all points, i.e. at 
every instruction of the relevant code, sin^Ufies ap- 
preciably and significantly the verification of subpro- 
grams, on the contrary, in the verification processes 
of the prior art, in the absence of such a constraint, 
the verification process maat establish that the sub- 
programs observe a strict stack discipline, and must 
verify the body of the subprograms polymorphous ly re 
garding the type of certain registers. 

in conclusions the verification process which is 
the subject of the present invention, compared to the 
techniques of the prior art, makes it possible, on the 
on6 hand, to reduce the size of the program code which 
makes it possible to carry out the verification method, 
and on the other hand, to reduce the consuntption of 
random-access memory during the verification opera- 
tions, the degree of complexity being of the form 
0(Tp+Pr) in the case of the verification process which 
is the subject of - the present invention, instead of 
(0(Tp+T.)^) for the verification process of the prior 
art, while however offering the same guarantees about 
the security of execution of the verified code. 

Finally, the process of transforming original 
traditional code into standardized code is iinplemented 
localized transfonnation of the code without trans- 
initting additional information to the verifier coim>o- 
nent. i.e. the microprocessor card or on-board data- 

processing system. 

Regarding the method of reallocating registers 
as described in figs. 4b and 5b, this method differs 
from the known methods of the prior art, as described 
in particular in. US Patents 4,5.71,678 and 5,249,295, by 
the fact that! 
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the rejfter reallocation ensures A tlxe same, 
register caimot be assigned to two intervale 
\,ith different main types, which thus guarantees 
that a given register is used with the saioe type 
throughout the code? and 

the existing register allocation algorithms, 
which are described in the abovementioned docu- 
ments, assume a fixed nuiriber of registers, and 
attentpt to minimize the transfers. called 
between registers and stack, whereas 
reallocation of registers as claiined in the sub- 
ject of the present invention operates in a 
framework where the. total number of registers is 
variable, as a consequence of which there is no 
purpose in carrying out transfers between regis- 
ters and stacks when a process of minindzing the 
total number of registers is carried out. 
The protocol for managing a program fragment 
downloaded onto an' on-board system, and the methods of 
verifying this downloaded program fragment and of 
transforming this object code of a downloaded program 
fragment respectively, which are the subjects of the 
present invention, can of course be implemented in 
software. 

Therefore, the present invention also concerns a 
cottputer program product which can be loaded directly 
into the internal memory of a reprogrammable on-board 
system, this on-board system making it possible to 
download a program fragment consisting of an object 
code, a series of instructions, executable the mi- 
croprocessor of the on-board system by way of a virtual 
machine equipped with an execution stack and with local 
registers or variables manipulated via these instruc- 
tions so that this object code can be interpreted. The 
corresponding con^mter program product includes por- 
tions of Object code to execute the protocol for manag- 
ing a program fragment downloaded onto this on-board 
Bystem. as shown in figs. 2 and 6 described above in 
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the description .^hen fchis on-board system intercon^ 
nected to a teiimnaL and this program is executed by 
the microprocessor of this on-board system by way of 

the virtual machine. 

The invention also concerns a coinputer program 
product which can be loaded directly into the internal 
memory of a reprogrammable on-board system, such as a 
microprocessor card with a rewritable • memory , as shown 
with reference to fig. 6. This con5,uter program product 
includes portions of object code to execute the stages 
of verifying a program fragment downloaded onto this 
on-board system, as shown and described above in the 
description, with reference to figs.. 3a to 3j. This 
verification is executed when this on-board system is 
interconnected to a teinninal and this program is exe- 
cuted by the microprocessor of this on-board system via 

the virtual machine. 

The invention also concerns a con«puter program 
product; this computer program product includes por- 
tions of object code to .execute the stages of the 
method of transforming the object code of a program 
fragment into standardized object code for this same 
program fragment, as shown in figs. 4a, 4b, 5a, 5b and 
-6, and described above in the description. 

The present invention also concerns a coitputer 
program product which is recorded on a medium which can 
be used in a reprogrammable on-board system, e.g. a mi- 
croprocessor equipped with a rewritable memory, this 
on-board system making it possible to download a pro- 
gram fragment consisting of an object code executable 
by this microprocessor, by way of a virtual tnachine 
equipped with an execution stack and local variables or 
registers manipulated via these instructions, to allow 
interpretation of this object code. The abovementioned 
coimniter program product includes, at least, a module 
-of - programs which can be read by the microprocessor of 
■ the on-board system via the virtual machine, to command 
«tecution of a proceoare for managing the downloading 
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of . a dovmloade^pfogram fragiiient, as shoJ^ in fig- 2 
and described : above in the description, a module o£ 
programs which can be read by the microprocessor via 
the virtual machine, to comtnand execution of a proce- 
dure for verifying, instruction by instruction, the ob- 
ject code which makes up this program fragment, as 
shown and described in relation to figs. 3a to 3j in 
the' description above, and a module of programs which 
can be read by the microprocessor of this on-board sys- 
tem via the virtual machine, to command execution of a 
downloaded, program , fragment following or in. the absence 
of a transformation of the object code of this program 
fragment into, a standardized object code for this same 
program fragment, as shown in fig. 2. 

The aboveraentioned computer program product also 
includes a module of programs which can be read by the 
microprocessor via the virtual machine, to command in- 
hibition of execution, on the on-board system, of the 
program fragment in the case of. an unsuccessful verifi- 
cation procedure of the abovementioned program frag- 
ment, as shown and described above in the description 
with reference to fig. 2. 
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Code of method 
being venfied 



aload 0 








sconst 3 


• 


saioad 




putiJfild C.f 










rcg2| ^_J-^ 
Table cf register types 



short ^ 
"short D*^ 



Type stack 



Type stack 
pointer 
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TABLE 2 ^ 
I>seudo-code of verifietr module 

PSEUDO-CODE OF VERIFIER HODPLE 
Globd variables used: 



Initialize p/i-^O 

Initialize tplO] ... Jp[n-I] from types of n arguments of method 
Initialize «pW ipI7>-ll to J- 
Initialize c/i;; to true 
While cA; is true: 

Reset cA|r to false 

Position on first instruction of method 
While end of method is ootreacbcd 

If current instruction is target of a tv^nchijig instruction: 

If pp4 0, verification fails 
If current instruction is target of a subroutine call: 

If previous instruction continues in sequence, failure 
Take ip[0]4^'mddf and pp^^ 
If cun«m instruction is an exception handler of dass C 

If previous instruction continues in sequence, failure 



Do J!p[0]^ C and pp^l 
If current instruction is a tatget of different kinds: 

Verification &il5 
Deicnnine types ... a, of arguments of instruction 
If p;7 < n, failure (stack overflow) 
For/= 1, -.-,n: 

If tplpp-n-i'l] is not subtype of failure 
"Doppi-pprn 

Determine types ..^ r« of results of instruction 
If p^fw^^ failuie (stack overflow) 
For/=l, „.,m,do//7(p/H-i-lJ7r, 
Dopp^pPHn 

Jf current instruction is a write to a register r: 



PP 



chg 



tr[TrJ 
tp(Tp} 



number of registers declared by current mdhod 

maximum site of stack declared by cutrmt method 

table of register types (402 in fig. 4) 

stack type (4()3 in fig. 4) 

stack pointer (404 in fig. 4) 

flag indicatmg whether tr has changed 
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DetciOTll ore / of value writtm to iccoM 

1>6tr[r]^la\9er bound itMr]) 
Utrir] has changed, do cAgf^tme 
If cmrent mstnicdon is a branchnig: 
5 If pp # 0, verification failure 

Advance to next instruction 
Rctum verification success code 



TABLE T3 



Static sJiorrQ iaeth(ghort Q table ) 
{ 

shored result = null; 
if ( table length >= 2) result = table; 
return table 
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Hrst iteratton on method code: 
Method code 



0 
I 
2 

i 

6 

7 
5 
9 

10 



sconst 2 



are turn 



Table of reg^terfypw 
— ' '_^xxi r 



I 



stack type 



TtI: Short U t I 



0: 




1 ; 




2 : 


aload 0 


3 : 




4 : 


fiConBt 2 


5 : 




7 ; 


~ alqad 0 


8: 


asxore 1 


9 : 


aload 1 


10: 


aretuni 



Second iteration on mettiod code: 



.. (TSi akortf tlTi: atiartLTI ^ 
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{AyVwlation of type constrawis on arguments cf an instruction: 

( lO; ObiBctl I 



0 ; 


sload 0 


1 : 


sconst 1 


2 : 


s&di 


3 : 


axetnXA 



. ( TO; Object i 

Error, stack type does not 
correspond to what Instruction 
expects (short, short) 



(b) Inconsistent use of a register: 




f rO; BUortl I 



\ yO: short i 
f rO: 1 



I 



CHEZ 



3 I 



J 



Error, stack type does not correspond 
to what Instruction expects (Object) 



0: 


Blosd 0 


I : 


if eq 8 - 


4: 


scosst 1 


5: 


goto 9 


fi: 




9: 


sxeturs 



(c) Branchings Introducing inconsistencies M stack Uvel: 

♦ prO: ahcxTl | 



Error stack not empty at branching point 



(d) Stack overflow within a loop: 

• | rPi atort \ | 
.:■ ( rO; t^orTl [ shoxt j 



0: 


sload 0 


a : 


iieq 21 - 


4 : 


scoost ] 


5 : 


aibc 0 -J 


8: 


goto 0. 


11 : 


return 



En^r stack not empty at branching point 



TABLE 




- I ro; Otject I fdbjcctl 

("r6; Object | f iat j 
•-•• I r^: dbjtet t j 



Ofc^oct I 1^ iat "1 
I rOi tot I j 



5 TABLE T7 

<^^Methcdcode^erstandardi^nofstackatbranchm^^ 



TABLE T8 
{ciM&hodcode 



'cation of registers: 



0: 
1 ; 
4 : 
4': 
a : 
8 : 
8' ; 
S" : 
9: 
10: 
U : 
12: 



aload 0 



ifnull 8 



i const 



istore \ 



goto 8" 



icoast 0 



istore 1 



iloaci 1 



iseg 



istore 1 



iload 1 



axetura 



rO: Ob1«ct I n: -i | | 



I r6: Object t Ti: X 



I rO; Obj€C^ } rl; inX 



T!T>i.... |^0; Object ) rl: j. j 

- I rO: Object \ rl: X j 



{ rO: bbjeet j rl: int 1 



I rO; Object | xl; X I 

• •' 1 tO: Object i rl; Int*"] 

•• j rO: Object \ rl; ini | 

■ ■ J rO: Object | rl: int | 

'• I TO; Object I rl; lat 

•« i lO.: Object ) rl; lat ^ 



int I 



iat I 



lat 1 



1^ 



iat \ 



TABLE T9 

{iii Branching target, previous instruction not continuing in sequence: 
Branching Brandling 



nor>-^. instr. 



stack state 
[£l3 



Standardization 



non-€eq. instr. 



1m4 ri 



izistructjon i 



■stack state 

I 



TABLE TIP 



(b) Branching targ^^revious instruction continuing in seqJI^: 



Branching 



seq.instr. 



ixkstxuciioa) { 



Branching 



Standardization 



soq. instr« 



store T2 



siore n 



load Ti 



insinxctioQ j 



[£] 
I 

S3 



TABLE Til 

(c) Unconditional branching without arguments: 

StandarcHzation 



goto 



T 

Target 



Target 



5tor« 
goto 



Eg 

I 



TABLE T12 • 
1 0 (c) Conditional branching with one argument: 



Target 



Standarc&ation 



{org 



Target 



svap^x 2,1 

•ton rj 

load n 
load r2 



□CJQ 



SI 
1 

® 



: CLAIMS 

1. A^plrptocol for managing, a p4l^^ fragment 
dpvThlpaded onto a reprogrammable on-board eysteni/ euch 
as. a microprocessor card equipped with a rewritable 
memory, said program fragment consisting of an object 
code, a series of instructions, executable by the mi- 
croprocessor of the on-bo€Lrd system by way of a virtual 
machine equipped with an execution stack and with local 
variables or registers manipulated via these instruc- 
tions and making it possible to interpret this object 
code, said an-board system being interccmnected to a 
terminal, characterized in that this protocol consists 
at least, at the level of said on-board system: 

a) in detecting a command for downloading of this 
program fragment; and, on a positive response to 
this stage consisting in detecting a downloading 
command, 

b) in reading the object code constituting this 
program fragment and in temporarily storing this 
object code; 

c) in evibjecting the whole of the object code 
stored temporarily in memory to a verification 
process, instruction by instruction, this veri- 
fication process consisting at least in a stage 
of initializing the type stack and the table of 
register types representing the state of said 
virtual machine at the start of the execution of 
the tenporarily stored object code and in a suc- 
cession of stages of verification, instruction 
by instruction, by discerning the existence, for 
each current instruction, of a target, branch- 
ing-instruction target, target of an exception- 
handler call, or target of a subroutine call, 
and in a verification and an updating of the ef- 
fect of said current instruction on the type 
stack and on the table of register types, and, 
in the event of a successfnl verification of 
said object cocTe, 



dy : in recording the' downloaded prograrn fragment in 
a diJPftory of available program wagments, and^ 
in the event of an unsuccessful verification of 
said object code, 

e) in inhibiting execution, on said on-board sys- 
tem, of said program fragment. 

2. Thq protocol as claimed in claim 1, charac- 
terized in that said stage e) of inhibiting the execu- 
tion consists: 

f ) in deleting the momentarily recorded program 
fragment, when omitting to record the latter in 
said directory of available program fragments, 
and 

g) in sending an error code to said reader. 

3 -The protocol as claimed in claim 1 or 2, char- 
acterized in that, on a negative response to said stage 
a) consisting in detecting a downloading command, this 
consists: 

b*} in detecting a command to select an available 
program fragment from a directory of program 
fragments; and, on a positive response to this 
stage, consisting in detecting a command to se- 
lect an available program fragment; 

c') in calling said selected available program frag- 
ment; 

d') in executing said called available program frag- 
ment via the virtual machine, with no dynamic . 
verification of variable types, access rights to 
the objects which are manipulated by the called 
available program fragment, or overflow of the 
execution stack when each instruction is exe- 
cuted, and, on a negative response to this stage 
consisting in detecting a command to select an 
available program fragment, 

e') in proceeding to process the standard commands 
of the on-board system. 

4. A method - of verifying a program fragment 
downloaded onto a reprogrammable on-board system, such 



as a microprocessor card equipped with a rewritable 
m^mpry^ said ^ogr am fragment consisting^^f an object 
code and including at least one subprogram^ a aeries of 
instructions, by the microprocessor of the on-board 
5 system by way of a virtual machine equipped with an 
execution stack and with operand registers manipulated 
by these instructions, and making it possible to inter- 
pret this object code, said on-board system b^ingr in- 
terconnected to a reader, characterized in that said 
10 method, following the detection of a downloading com- 
mand and the storage of said object code constituting 
this program fragment in said rewritable memory, con- 
sists, for each subprogram: 

a) in carrying out a stage of initializing the type 

15 stack and the table of register types by data 

representing the state of the virtual machine at 
the start of the execution of the temporarily 
stored object code; 
p) in carrying out a verification of said temporar- 

20 ily stored object code instruction by instruc- 

tion, by discerning the existence, for each cur- 
rent instruction^ of a target, a branching- 
instruction target, a target of an exception- 
handler call or a target of a subroutine call; . 

25 y) in carrying out a verification and an updating 

of the effect of said current instruction on the 
data types of said type stack and of said table 
of register types, on the basis of the existence 
of a branching^instruction target, of a target 

30 of a subroutine call or of a target of an excep- 

tion-chandler call, said verification being suc^ 
cessful when the table of register types is not 
modified in the course of a verification of all 
the instructions, and the verification process 

35 being carried out instruction by instruction un- 

til the table of register types is stable, with 



no modification present, the veriff cation proc- 
ess bd^g interruipted othezvis^. 
5- Th© verification mathod as filaimed in claim' 
4r characterized in that the variable types which are 
5 manipulated during the verification process include at 
least : 

class identifiers corresponding to object 
classes which are defined in the program frag- 
ment; 

10 - numeric variable types including at least a type 

short , an integer coded on p bite, and a type 
retaddr for the return address of a jump in- 
struction JSR; . . 
a type null relating to references of null ob- 

15 jects; 

a type object relating to objects; 
a first specific type representing the in- 
tersection of all the types and corresponding to 
the value 0, nil ; 

20 - a second specific type T, representing the union 

of all the types and corresponding to any type 
of value. 

6. Method as claimed in claim 5, characterized 
in that all said variable types verify a siabtyping re- 

25 lations 

ob j ect € T; 

short , retaddr e T; 

J- c null, short , retaddr • 

7. The method as claimed in one of claims 4 to 
30 6, characterized in that when said current instruction 

is the target of a branching instruction, said verifi- 
cation method consists in verifying that the type stack 
is eirpty, the verification process being continued for 
the following instruction in the case of a positive 
35 verification/ and the verification process failing and 
the program fragment being rejected otherwise. 



8. The methoa asi. claimed in one of claims 4 to 
: 7 , Gharacteri^ in that when said ciurrd^ instruction 

is the target of a subroutine call, said verification 
process verifies that the previous instruction is an 
5 imconditional branching, a subroutine return or a rais- 
ing of an exception, said verification process, in the 
case of a positive verification, proceeding to reupdate 
the stack of variable types by an entity of retaddr 
type, the return address of the subroutine, and the 
10 verification process failing and the program fragment 
being rejected otherwise. 

9. Hie method as claimed in one of claims 4 to 

8, characterized in that when the current instruction 
is the target of an exception handler, said verifica- 

15 tion process verifies that the previous instruction is 
an xaiconditional branching, a subroutine return or a 
raising of an exception, said verification process, in 
the case of a positive verification, proceeding to re- 
update the type stack by entering the exception type, 

20 and the verification process failing and the program 
fragment being rejected otherwise. 

10. The method as claimed in one of claims 4 to 

9, characterized in that when the current instruction 
is the target of multiple incompatible branchings, the 

25 verification process fails and the program fragment is 
rejected* 

11. The method as claimed in one of claims 4 to 

10, characterized in that when the current instruction 
is not the target of any branching, the verification 

30 process continues by passing to an update of the type 
stack. 

12. The method as claimed in one of claims 4 to 

11, characterized in that the stage of verification of 
the effect of the current instruction on the type stack 

35 includes, at least: 

a stage of verifying that the type execution 
stack includes at least as many entries as the 
current instruction includer operands; 



a stage of une tacking and of verifying that the 
types the entries at the top ojl^he stack are 
subtypes of the types of the operands of the op- 
erands of this instruction; 
5 _ a stage of verifying the existence of a suffi- 

cient memory space on the type stack to proceed 
to stack the results of the current instaniction; 
a stage of stacking on the stack data types 
which are assigpaed to these results. 

13 . The method as • claimed in claim 12 , charac- 
terized in that when the current instruction is an in- 
struction to read a register of address n, the verifi- 
cation process consists: _. - 

in verifying the data type of the result of this 
3^5 reading, by reading the entry n in the table of 

register types; 

in determining the effect of the current in- 
struction on the type stack by unstacking the 
entries of the stack corresponding to the oper- 
20 ands of this current instruction and by stacking 

the data type of this result . 

14. The method as claimed in claim 12, charac- 
terized in that when the current instruction ia an in- 
struction to write to a register of address m, the 

25 verification process consists: 

in determining the effect of the current in- 
struction on the -type stack and the type t of 
the operand which is written in this register of 
address m; 

30 - in replacing the type entry of the table of reg- 

ister types at address m by the type immediately 
above the previously stored type and atoove the 
type t of the operand which is written in this 
register of address m. 



15. A^ethod of transforming an oMect code of a 
program fragJRt, in which the operanc^^of each in- 
struction belong to the data types manipulated by this 
instruction, th© execution stack does not exhibit any 
overflow phenomenon, for each branching instruction, 
the type of the stack variables at this branching is 
the same as at the targets of this branching, into a 
stetndardized object code for this same program frag- 
ment, in which the operands of each instruction belong 
to the data types manipulated by this instruction, the 
execution stack does not exhibit any overflow phenome- 
non, the execution stack is eitpty at each branching in- 
struction and at each branching- target instruction, 
characterized in that this method consists, for all the 
instructions of said object code: 

in annotating each current instruction with the 
data type of the stack before and after execu- 
tion of this instruction, the annotation data 
being calculated by means of an analysis of the 
data stream relating to this instruction; 
in detecting, within said instructions and 
within each current instruction, the existence 
of branchings, or respectively of branching- 
targets, for which said execution stack is not 
empty, the detection operation being carried out 
on the basis of the annotation data of the type 
of stack variables allocated to each current in- 
struction, and in the presence of detection of a 
non-enpty execution stack, 

in inserting instructions to transfer stack 
variables on either side of these branchings or 
of these branching targets, respectively in or- 
der to en©ty the contents of the execution stack 
into temporary registers before this branching 
and to reestablish the execution stack from said 
teirporary registers after this branching, and in 
not inserting any transfer instruction other- 
wise, making it possible to obtain a standard- 



mi ux/ 

ized o^ct code for this some pro»ro fragment, 
in vihi^ the execution stack is Wpty at each 
branching instruction and at each branching- 
target instruction, in the absence of any modi- 
fication to the execution of said program frag- 
ment. 

16. A method of transforming an object code of a 
program fragment, in which the operands of each in- 
struction belong to the data types tr^nipulated by thxs 
instruction, and an operand of given type written into 
a register by an instruction of this object code xs re- 
read from this same register by another instruction of 
this object code with the same given data, type, xnto a 
standardised object code for this same program frag- 
:„ent. in which the operands of each instruction belong 
to the data types manipulated by this i^truction, the 
3«ne data type being allocated to the same register 
throughout said standardised object code, cha^acterxzed 
in that this method consists, for all the instructions 

of said object code: ^. .^y, 

in annotating each current instruction wxth the- 
data type of the registers before and after exe- 
cution of this instruction, the annotation data 
being calculated by means of an analysis of the 
data stream relating to this instruction; 
in carrying out a reallocation of the registers, 
by detecting the original registers en©loyed 
with different types, by dividing these original 
registers into separate standardized registers, 
one standardized register for each data type 
used, and reupdating the instructions which ma- 
nipulate the operands which use said standard- 
ized registers. 

17. «ie method as claimed in claim 15. charac- 
terized in that the stage .consisting in detecting, 
^thin said instructions and within each current in- 
struction, the existence of branchings, or respectxvely 
of branching targets, f or ..hich the execution stack is 



xv9tv«npty. co08ts, fOliowing detedtion |^ea<di corre- 
sponding instruetion p£ rank i: 

- ; in associating with each instruction of rank i a 

set of new registers, one new register being as- 
sociated with each stack variable which is ac- 
tive at this instruction; 

in examining each detected instruction of rank i 
and in discerning the existence of a branching 
target or branching, respectively, and, in the 
case where the instruction of rank i is a 
branching target and that the execution stack at 
this instruction is not empty, 

• for every preceding instruction, of rank 
i-1, consisting of a branching, a rais- 
ing of an exception or a program return, 
the detected instruction of rank i being 
accessible only by a branching, 

in inserting a set of load instructions 
• load to load from the set of new regis- 
ters before said detected instruction of 
rank i, with redirection of all branch- 
ings to the detected instruction of rank 
i to the first inserted load instruction 
load ; and 

• for every preceding instruction, of rank 
i-1, continuing in sequence, the de- 
tected instruction of rank i being ac- 
cessible simultaneously by a branching 
and from the preceding instruction of 
rank i-1, 

in inserting a set of backup instruc- 
tions store to back up to the set of new 
registers before the detected instruc- 
tion of rank i, and . a set of load in- 
structions load to load from this set of 
new registers, with redirection of . all 
the branchings to the detected inwtruc- 



^ion of rank i to the f^st inserted 
•[oa<a instruction load, an^in the case 
where said detected instruction of rank 
i is a branching to a given instruction, 
for every detected instruction of rank i 
consisting of an unconditional branch^ 
ing» 

in inserting, before the detected iii- 
struction of rank i, inultiple backup in- 
structions store, a backup instruction 
. being associated with each new register; 
and 

for every detected instruction of rank i 
consisting of a conditional branching, 
and for a number m > 0 of operands ma- 
nipulated by this conditional branching 
instruction, 

in inserting, before this detected in- 
struction of rank i, a perniutation in- 
20 struction, swap-x , at the top of the 

execution stack of the m operands of the 
detected instruction of rank i and the n 
following values, this permutation op- 
eration jnaking it possible to collect at 
the top of the execution stack the n 
values to be backed up in the set of new 
registers, and 

in inserting, before the instruction of 
rank i, a set of backup instructions 
store to back up to the set of new reg- 
isters, and 

in inserting, after the detected in- 
struction of rank i, a set of load In- 
structions load to load from the set of 
_c new registers. 

18. -me method as claimed in claim 16, charac- 
terized in that the stage consxetioig in reallocating 



registers by .^tecting ilie original resi||^rs ernployed 
^/ifch different types cisnfiilsts: 

in determining the lifetime iiitervals of each 

register; 

in determning the main data type of each life- 
time interval, the main data type of a lifetime 
interval j for a register r being defined by the 
upper bound of the data types stored in this 
register r by the backup instructions store be- 
longing to the lifetime interval j; 
in establishing an interference graph between 
the lifetime intervals, this interference graph 
consisting of a non-oriented graph of . which each 
peak consists of a lifetime interval, and of 
which the arcs between two peaks ji and exist 
if a peak contains a backup instruction ad- 
dressed to the register of the other peak or 
vice versa; 

in translating the uniQueness of a data type 
which is allocated to each register in the in- 
terference graph, by adding arcs between all 
pairs of peaks of the interference graph while 
two peaks of a pair of peaks do not have the 
same associated main data type; 
in carrying out " an instantiation of the inter- 
ference graph, by assigning to each lifetime in- 
terval a register number, in such a way that 
different register numbers are assigned to two 
adjacent life intervals in the interference 
graph. 

19. An on-board system which can be reprogrammed 
by downloading program fragments, including at least 
one microprocessor, one random^access memory, one xn- 
put/output module, one electrically reprogrammable non- 
volatile memory and one permanent memory, in which are 
installed a main program and a virtual machine which 
n«kes it possible to execute the main program and at 
least one program, fragment using said microprocessor. 



SSt one ™^.le tc ™a^.e and ^ify a 

tion progr™ moduXe being Installed In the pex,«nent 

20 *n on.boara Byet«. which can be r.prog«M»d 
d^nloadin. P«,ra« fr„.nents, including at Xeast 
1 ^cropro=aes«. on. randon.-a=ce,s '^'^'^ 2- 
put/cutput module, on. electrically reprogra«able non 

ixr^en^xv and one pen^nent «-no.y. ^-J*-^* 
instaxxed a ™in program and a virtuaX J^^* 
it possibXe to execute the .-in program and at 
Program frag^^t usi^g said.,microprocessor 
Characterized in that eaid on-board system 
least one program module to manage and verity a do«n 

<= in aeeo«lanoe with the protocol 

loaded program fragment in aceonwn _iai»eol 
for managing a downloaded program fragment aa claimed 
i„ one of Claims X to 3. said .»nage.«nt and verifica- 
tion progr^n modale being installed in the per^nanent 

n «>e on.b=ard syst«. as claimed in claim 20. 
Characterised in that it includes at ^^^^r^^ 
gram module to verify a apwnloaded program fr.gm«^. in 
'ccordance with the verification proc claimed in 

one of claiacis 4 to 14. ^ „ 

22. A method of transforming an obiect code of a 

program fragment, in which the ^^^^ ^'J^^ 
atruction belong to the data types 

instruction, the execution stack does not exhibit any 
instruct branching instruction, 

overflow phenomenon, for each oran si . 
the type of stack variables at this branching « the 
^ as at the targets of this branching, and an^- 
^ of given type written to a register by an instruc 
To. of this Object code is reread from this same re^ 
TsL by another instruction of this object code with 
^a si given data type, into a standardized object 
*L for this same program fragment, in which the op^- 
Of each instruction belong to the data typee ma- 



Hlpulated by instruction, the execut^ stack does 

not exhibit ovifflow phtoomenon, the execiJWon stack is 
en«>ty at each branching instruction and at each branch^ 
ing-target instruction, the same data type being as- 
signed to the same register throughout said standard- 
ized object code, characterized in that said conversion 
system includes, at least, installed in the working 
n^aory of a development computer or workstation, a pro- 
gram module to transform this object code into a stan- 
dardi^ed object code in accordance with the method as 
claiined in one of claims 15 to 18, making it possible 
to generate a standardized object code for said program 
fragment, satisfying the criteria for verifying thxs 
downloaded program fragment. 

23. A coinputer program product which can be 
loaded directly into the internal memory of a r^ro- 
grammable on-board system, such as a microprocessor 
card equipped with a rewritable memory, this on-board 
system making it possible to download a program frag- 
ment coneisting of an object code, a series of instruc- 
tions, . executable by the microprocessor of the on-board 
system by way of a virtual machine equipped with an 
execution stack and with local variables or registers 
manipulated via these instructions and making it possi- 
ble to interpret this object code, this cort^ter pro- 
gram product including portions o£ object code to exe- 
cute the protocol for managing a downloaded program 
fragment on this on-board system as claimed in one of 
claims 1 to 3. when this on-board system is intercon- 
nected to a terminal and this program is executed by 
the microprocessor of this cn-boar^ system by way of 

said virtTial machine. 

24. A consniter program product which can be 
loaded directly into the internal memory of a repro-- 
granor^ble on-board system, such as a microprocessor 
card equipped with a rewritable memory, this on-board 
system making it possible to download a program f rag- 

. ment consisting of an objoct code, a series of instruc- 



ti««. executa^ by the >lcropro«wcr pfjhe on-board 
systin. by'vay^f 9 virtual «aohine equlWed with an 
execution stack and with eper»«l register, .nanipulated 
via these instructions and makina it possible to inter- 
pret this, object code, this c<.»putar program product 
including portions of object code to execute the stages 
of verifying a program fragn«nt downloaded onto thxs 
on-board system as claimed in one of clai^ 4 to 14, 
when this on-board system la intercormected to a termi- 
ni ^d this prograa, is executed by the microprocessor 
Of this cn-board system by way of said virtual mchine. 

25. A con!PUter prograT product including por- 
tions of object code to execute stages of the method of 
.r^.t.m^. - cbiect code o£ a d»^oaded program 
fragment into a standardised object ^. 
program fragir«nt as claimed in one of cla^ 15 to 18 

° 26. A computer program pro*act which is recorded 
„ a medium which can be used in a 

board system, such as a microprocessor card e-^ipp.d 
with a rewritable memory, this on-board system mafang 
it possible to download a program fragment consisting 
L L object code, a series of instructions, executable 
by the ndcroprocessor of the on-board syst«. by way of 
Tvirtual machine eauiPPed with an execution stack and 
with local variables or registers .^aipulated v.a these 
I^tructions and making it possible to ^^e^-t tbi. 
object code, this computer program pro*ict xncluding, 

program resources which can be read by the mi- 
croprocessor of this on-board system via saxd 
virtual machine, to command execution o£ a pro- 
cedure for managing the downloading of a down- 
loaded program fragment? 

program resources which can be read by the mi- 
croprocessor of this on-board system via said 
virtual machiiie. to command execution of a pro- 
cedure for verifying, instruction by instruc- 



10 



15 



tion, object code which makes^p said pro- 

program resources which can be read by the nd- 
croprocessor of this on-board system via said 
virtual machine, to command execution of a down- 
loaded program fragment following or in the ab- 
sence of a conversion of the object- code of this 
program fragment into a standardized object code 
for this same program fragment. 
27. The coinputer program product as claimed in 
claim 26, additionally including program resources 
which can be read by the microprocessor of this on- 
board system via said virtual machine, to command inhi- 
bition of execution, on said on-board system, of said 
program fragment in the case of an unsuccessful verifi- 
cation, procedure of this program fragment. 
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